So I'm working on a mobile app that's driven by a node.js API. My question is, for hashing/storing passwords would it be better to hash them in the node API (with Bcrypt) then send this to the Postgres database, or should I send the plaintext password to the database and hash it using the crypt() function that is in pgcrypto.
If you send it to the database in plaintext, that is just one more spot where it can be accidentally logged or leaked, or spotted in transit. Why do that if you don't need to? If node.js has a trustworthy bcrypt API, then use it rather than using pgcrypto's.
Related
I'm learning about web security, hashing and encryption stuff.
I'm building an authentication feature for an API REST backend app. I had an idea and i wanted to know your opinion.
What if we apply data validations on "clear" password that we are supposed to recieve from the client ?
From a backend perspective, accepting only password data in a bcrypt hash form. The password would have to be hashed by the front app, sended to the backend, hashed again to compare with the password in DB.
Scheme picture :
It could really increase the bruteforce load and time consumption and the clear/real user passwords would never go out from the user RAM.
I think it could be a good idea but i don't have enough knowledges to apply it blindlessly.
This question already has answers here:
Is it worth hashing passwords on the client side
(13 answers)
Closed 2 years ago.
I'm reading a lot about security lately and something really bothers me.
I'm using Node.JS and I wanna store user data in the database. I currently hash the password on the server and then I save it to DB. But when the user sends data to the server he sends just plain text. I think that is the wrong approach. I'm using Bcrypt btw.
The method that I wanna use is: when a user need's to sign in I hash the password on the client, and then I send a hashed password with a salt to the server. The server then hashes the password again and stores the result in DB alongside with the first salt, that the user has passed. That means I have serverHash(userHash(userPassword)) and userSalt.
When the user then does log in, I wanna fetch him a userSalt from DB and hash his userPassword using that salt. Then I send userHash(userPassword) to the server and then compare userHash(userPassword) and serverHash(userHash(userPassword)).
Is this method good and secure, or is there a better way to do this, can I maybe use some third-party library or I can get away with this approach?
EDIT:
If someone bumps into this, don't do this, TLS will probably do the job, if not there are certificates that will help I think, I'm not 100% sure, but don't take my word for it but.
Purpose of Database Hashing Password
hashing password in server solve worries about accidental access to database.
where we consider server script are executing in a safe environment.
Authorized User can leak any data without protection
when a user login using username/password we will give him/her Authorization to Actions and view some Data .
if any crackers intrudes:
our server script
client browser or
intermediate media (network interception)
our goal (protect authorization) will be ruined.
so hashing the password on client-side dosen't solve any issue, if a
cracker can access to client-side area or intercept the traffic
data.
for example : an authorized admin, with heavy password protection mechanism,
can leak html data which tends to be admin-only viewable, if a cracker just intercepts network traffic.
Solution : Traffic Encryption
instead of sending hashed-password to server-side, The connection should get Encrypted like with SSL.
Todays Web Development
in Web Development its a good practice to to use HTTPS (Http+Ssl) when dealing with sensitive Data and Actions (scenarios which includes logins)
even in modern browsers, they show a Warning when dealing with html <input type='password'/> and not using Https.
I have a Laravel existing project where they use Laravel default encryption (i.e Hash::make('')) for user registration,so in database they saved the data with this encryption format.
Now I am creating API's using Node for the same MySQL database.So for those password decryption I have used Node bcrypt package.But the decryption is not working and I am getting error for JWT authentication token.I have used "algorithm": "RS256" for this Node API.So can anyone tell me if I did something wrong or I have to choose another package(in node) or any other algorithm(in node).
I think that is becrypt. Now when I am creating the API's with Node I have used Node be
Passwords in Laravel are hashed, which is different to encrypt them, because Hash is not reversible, when encryption can be reversed.
Furthermore, in order to let Node be able to decrypt encrypted data, you should share with Node the key that Laravel has used to encrypt that data, and that's absolutely very dangerous, because everyone than can have that key, and so if he finds a breach in you sql, like a possibility to run SQL injection, than he can use that key to decrypt that data
I am making a chat room with socket and node, I want an admin area, so lets say the chat is at localhost:3000. I don't want the admin area to be /admin for obvious security reasons I am very new to socket and node in fact this is the first app I am creating using these technologies..
So what would be the best solution for a secure admin area..? This has to be done quite quickly and the app has no database so I think a login would be out of the question.. or I could have a login with a static username and password? Is this secure..? I am really not too sure.
Regards
Implementing login would be the best option here. If you are not using any database, you can rely on alternate storing mechanism like in-memory storage or file systems storage to save admin credentials. It is up to your requirement whether to use persistent or non-persistent storage meshanism.
You may use npm modules like bcrypt to hash passwords while saving in storage, if you want to implement security.
var bcrypt = require('bcrypt');
bcrypt.genSalt(10, function(err,salt){
bcrypt.hash(myPassword,salt,function(err,hash){//use the hashed value 'hash' here
});
});
This will defend from threats like Rainbow Table Attacks.
I'm wondering what is the state-of-the-art of transmitting passwords from a web form and storing them in the data store.
A lot of recent posts point to bcrypt, however, there are no pure Python implementations, which is a requirement for App Engine.
Any suggestions?
Best practice? Use the Users API with either Google Accounts or OpenID, so you're not storing or transmitting passwords in the first place.
If you must do it yourself, transmit the login data over SSL, and store the password hashed, salted, and strengthened, using a scheme such as PBKDF2.
You can use PyCrypto which has been ported to google-app-engine.
You should never store the actual passwords, of course. Storing a hash should be sufficient. When the user enters his password, you hash it again and compare it to the stored value.
You should of course only receive passwords over https, which is supported in google-app-engine (albeit only through you appspot domain)
BCrypt has been ported to Python some time ago. I've been using it gracefully since then.