Developers October 21, 2020

Password hashing using NodeJs

LynnCobos

Hi,

I want to perform password hashing using NodeJs application. Need some guidance in the implementation part where I am mainly stucked.

  1. 9

    Have a look at bcrypt

  2. 2

    Bcrypt, or use something like Auth0 to manage your users’ accounts.

  3. 1

    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).

  4. 1

    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/

  5. 1

    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.

  6. 1

    https://nodejs.org/api/crypto.html#crypto_crypto_scrypt_password_salt_keylen_options_callback

    1. Choose any string as salt. Store it only in your code
    2. Store only hashed passwords. NEVER store plain passwords
    3. When authenticating hash password and compare it with already hashed password from DB

    That's it

    1. 2

      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.

      1. 1

        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

        1. 2

          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.

          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)

          1. 1

            You right. Thank for you time deeply explaining something to a complete stranger

  7. 1

    What are you trying to do?

  8. 0

    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.

    1. 1

      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.

      1. 3

        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.

        1. 3

          Yes that indeed makes sense.

        2. 1

          I think that connecting with those services is more complex and error-prone than just hashing passwords for inexperienced devs.

          1. 2

            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.

Recommended Posts