4

I am building a website that requires the users to login through username and password. I have the passwords encrypted in my database with bcrypt. On the back end, I receive the usernme and password of the user, and use this code to check it:

bcrypt.compare(req.body.password, result[0].password, function(err, success) {...})

At this point, if the compare is successful, I could simply use console.log(req.body.password) and get the users password printed out on my console. I mean, I probably just realized something that have been like this all the time. Is this safe enough?

  • 4
    A note on terminology: If you are using bcrypt, your passwords are not encrypted, they are hashed. That is a good thing - they should be hashed, not encrypted. – Anders Oct 17 at 8:09
  • 1
    I see, thanks for pointing that out. They should have named it bhash to avoid confusion :) – devamat Oct 17 at 8:59
  • If you're the coder (ie: can change the website code), you can just dump the password too (anywhere you want) when user registers. Or dump their session cookie. Or make an action on their behalf. You're the one the client trusts (they trust your code, so they trust anyone who can edit it) – Xenos Oct 17 at 15:31
3

For most purposes that is secure enough minus the logging.

Your server must have the plain text password at one point, whether it's signing up or logging in. In this case, the user is passing their password to the API through an HTTPS POST request, the server is verifying the password against a hashed and salted password with many salt rounds using bcrypt and ideally generating a JWT after authentication. There is no way for an outsider (or you) to access the password. It was transfer securely through the internet, then it didn't leave your secured server (unless you log it). Do be diligent with logs; make sure no PPI including passwords are being logged (some companies do this and it really drives me nuts).

Notes:

  1. The passwords are hashed as opposed to encrypted, in general and with bcrypt (though depending how deep you want to dive, you could argue bcrypt "does" encryption, but not for the reason you think). Always refer to "hashed" passwords because encryption refers to something entirely different.

  2. Assuming the server is securely hosted (if using a 3rd party container service, this is probably true)

  3. Assuming the password is given to the API through HTTPS and cannot be intercepted during transit. Depending on the application, you may want to go as far as certificate pinning to avoid MITM attacks through HTTPS.

By using bcrypt, you have already done your part in securely storing relatively passwords -high five-. You can also explore scrypt or Argon2.

2

This is expected and nothing strange. While you handle sign up and log in requests, your server will need to have the password in plain text so that it can be hashed. That's how most sites using passwords work. What is important is that they are never stored (in database, logs, anywhere) in plain text. If you keep using bcrypt and don't actually log the passwords you'll be fine.

If you want to protect the server from ever seeing the plain text password, you could implement client side hashing. It is important to remember that client side hashing is not a replacement for server side hashing - you will still need to use a strong hashing algorithm on the server side. I would say that client side hashing is usually overkill, and not very effective.

A note on terminology: If you are using bcrypt, your passwords are not encrypted, they are hashed. That is a good thing - they should be hashed, not encrypted.

  • 1
    Just to add to the argument against client side hashing, I'd say it's not useful at all and adds nothing to the security of the system. If the client hashes a password and sends you the hash, that hash has now become the password. An attacker no longer needs the original password to login, just the hash. – Chris Murray Oct 17 at 10:53
  • 1
    @ChrisMurray Yes, that is why I say it is not a replacement for server side hashing. Doing both does not come with the problems you describe. But I agree it is still not very useful. – Anders Oct 17 at 13:01
  • Actually you would not want client side hashing - where the hash basically becomes the password - but rather something like SRP where you can authenticate without ever knowing the password but also without ever having access to anything that would let you authenticate again in the future without knowing the password. – Ben Oct 17 at 20:55
0

If you want minimize such impact from 3d party website admins, you can implement a zero-knowledge proof protocol instead of bcrypt for user authentication. For instance, SRP-6 is widely used and implemented. Briefly, it provides enough protection from server database leak and Man-in-the-Middle attacks as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.