passport and passport-local should be your default, I wouldn't try to do low-level "roll your own auth" in Node like you might with PHP/MySQL or other web technologies. Use an auth framework that comes with an understanding of hashing, storage, cookie encryption, sessions, and OAuth (there's very little to no benefit to rolling your own in the Node ecosystem).
Try to build on top of a framework that handles password hashing for you. There's very little reason for a developer to spend time plumbing password management nowadays when there's so solutions available that are known to be secure.
I think the better way to handle salting is to generate a unique salt per user and store it in DB next to the password, not to just store a static salt in code.
There are many reasons for this, but a really important one is that this way two users that use the same password will still have different hashes.
Storing salt only next to password kills idea of salt: separating one part of hash from another. So if somebody stole only DB, she couldn’t try all hashing functions on theirs password and then restore all passwords by brute force
Storing salt only next to password kills idea of salt
Actually the salt values are not secretes, you can store them in plaintext. Storing them in DB next to the password is reasonable and recommended (if an unique salt is used per user). The main reason why salts are used is to avoid rainbow tables (eg. we know the hash of "pass123" is XYZ, so if we found the XYZ hash in db we can find the original password without breaking the encryption). When you add salt "pass123UNIQUESALT" the hash will be unique too, so it won't be found in any rainbow tables. The only way to break the encyrption in this case would be through brute-forcing, which should take a really long time for good encryption.
Having the salt might help you brute-force easier, but for a strong password it should still be hard to break the encryption.
Having the salt as a secret doesn't really help, as if the hacker manages to brute-force the hash, it will find "pass123UNIQUESALT" as the solution, and if a DB breach happens than he will also find another password like "pass567UNIQUESALT", thus finding the actual salt value.
tl;dr: The main purpose of salting is to protect against rainbow tables. The main reason of having unique salt per user is to protect against same passwords leading to the same hash.
Best advice I can give is not to do it. It is so easy to screw up and darkweb is littered with passwords from hacks where developers made a small oversight.
Do i get you right, that you suggest to store passwords in plain text because when hashing them its easy to screw up? Storing them in plain is screwing up without even trying to not screw up.
Oh no, that’s not what I’m saying. I’m saying do not handle passwords at all unless it is an absolute necessity. Use Auth0, Firebase, or anything else that will handle passwords for you.
I only agree with that if it’s prefaced with the developer taking a course on encryption.
Just like in your comment above, “I think the better way to handle salting is to generate a unique salt per user and store it in DB next to the password,” the rationale for generating unique salt per user is not obvious to people and many tutorials on the web would not mention it. It’s only obvious after understanding how hashing actually works and understanding why it failed in protecting the user passwords in cases like the linkedin hack. When you add it up in aggregate, I would say using an external provider like Auth0, Firebase, or even just using Google login is easier.
Have a look at bcrypt
bcrypt is very widely used.
https://www.npmjs.com/package/bcrypt
This article talks about password hashing in NodeJs using better-suited functions such as Bcrypt, PBKDF2, and Argon2.
https://mojoauth.com/blog/hashing-passwords-in-nodejs/
Hope this helps!
Bcrypt, or use something like Auth0 to manage your users’ accounts.
passport
andpassport-local
should be your default, I wouldn't try to do low-level "roll your own auth" in Node like you might with PHP/MySQL or other web technologies. Use an auth framework that comes with an understanding of hashing, storage, cookie encryption, sessions, and OAuth (there's very little to no benefit to rolling your own in the Node ecosystem).Hey I read this really cool article on the same. It may be useful to you too.
https://www.loginradius.com/engineering/blog/password-hashing-with-nodejs/
I prefer Argon2 over Bcrypt
https://github.com/ranisalt/node-argon2
Try to build on top of a framework that handles password hashing for you. There's very little reason for a developer to spend time plumbing password management nowadays when there's so solutions available that are known to be secure.
Bcrypt!
https://nodejs.org/api/crypto.html#crypto_crypto_scrypt_password_salt_keylen_options_callback
That's it
I think the better way to handle salting is to generate a unique salt per user and store it in DB next to the password, not to just store a static salt in code.
There are many reasons for this, but a really important one is that this way two users that use the same password will still have different hashes.
You could also combine those two methods.
Storing salt only next to password kills idea of salt: separating one part of hash from another. So if somebody stole only DB, she couldn’t try all hashing functions on theirs password and then restore all passwords by brute force
But you are right two salts is a way to go
Actually the salt values are not secretes, you can store them in plaintext. Storing them in DB next to the password is reasonable and recommended (if an unique salt is used per user). The main reason why salts are used is to avoid rainbow tables (eg. we know the hash of "pass123" is XYZ, so if we found the XYZ hash in db we can find the original password without breaking the encryption). When you add salt "pass123UNIQUESALT" the hash will be unique too, so it won't be found in any rainbow tables. The only way to break the encyrption in this case would be through brute-forcing, which should take a really long time for good encryption.
Having the salt might help you brute-force easier, but for a strong password it should still be hard to break the encryption.
Having the salt as a secret doesn't really help, as if the hacker manages to brute-force the hash, it will find "pass123UNIQUESALT" as the solution, and if a DB breach happens than he will also find another password like "pass567UNIQUESALT", thus finding the actual salt value.
tl;dr: The main purpose of salting is to protect against rainbow tables. The main reason of having unique salt per user is to protect against same passwords leading to the same hash.
The second salt you are referring to, is actually called "pepper", and that indeed is like a "secret salt". See more info here: https://en.wikipedia.org/wiki/Pepper_(cryptography)
You right. Thank for you time deeply explaining something to a complete stranger
What are you trying to do?
Best advice I can give is not to do it. It is so easy to screw up and darkweb is littered with passwords from hacks where developers made a small oversight.
Do i get you right, that you suggest to store passwords in plain text because when hashing them its easy to screw up? Storing them in plain is screwing up without even trying to not screw up.
Oh no, that’s not what I’m saying. I’m saying do not handle passwords at all unless it is an absolute necessity. Use Auth0, Firebase, or anything else that will handle passwords for you.
Yes that indeed makes sense.
I think that connecting with those services is more complex and error-prone than just hashing passwords for inexperienced devs.
I only agree with that if it’s prefaced with the developer taking a course on encryption.
Just like in your comment above, “I think the better way to handle salting is to generate a unique salt per user and store it in DB next to the password,” the rationale for generating unique salt per user is not obvious to people and many tutorials on the web would not mention it. It’s only obvious after understanding how hashing actually works and understanding why it failed in protecting the user passwords in cases like the linkedin hack. When you add it up in aggregate, I would say using an external provider like Auth0, Firebase, or even just using Google login is easier.