1

This question already has an answer here:

I read this related article: Hashed pw storage with random salt which is kind of related to my question, but in the question and in the answers as well they mention to store the random salt used to hash the password in the database.

Now I'm using bcrypt to hash passwords and upon hashing the password I generate a random salt and hash with that BUT I do not store the salt afterwards because bcrypt can verify without it. Is it a good/bad practice? If so, why?

marked as duplicate by Steffen Ullrich, Community May 25 '18 at 11:51

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3

Can't comment, so I'll answer. Bcrypt already adds a salt. Is there a reason you want to salt the password twice?

As Steffen Ullrich pointed out in the possible duplicate question (https://security.stackexchange.com/a/184800/178931):

From a description of bcrypt at Wikipedia: ... The rest of the hash string includes the cost parameter, a 128-bit salt (Radix-64 encoded as 22 characters), and 184 bits of the resulting hash value (Radix-64 encoded as 31 characters) Thus, the salt is automatically included in the output string which means there is no need to add it by yourself.

The hash produced by the bcrypt function contains random salt. This way the salt doesn't need to be stored anywhere else. Wikipedia has a good article on bcrypt: https://en.wikipedia.org/wiki/Bcrypt

  • I didn't know that. Does that mean that when using bcrypt.hash(plain_pwd) it will automatically salt it? Or does it mean I still need to generate a salt but i do not need to store it?! – Jim-Y May 25 '18 at 11:28
  • @Jim-Y Yes, it does mean that bcrypt will automatically salt your password. This is done to protect the hashes from rainbow tables. I edited my answer – Aulis Ronkainen May 25 '18 at 11:39

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