Geek Answers Handbook

Salty hashed password with Python (different salt for each new password)

As I understand it, after reading and researching, the purpose of using the salt should be a different salt for each individual password that will be stored.

If the same salt is used to store the entire password, I can figure out how to implement this, since I could just store the salt in a constant private variable and use it. But this is not so.

Although it makes sense to store each new password with a new salt, how can I guess which user password is associated with the salt? The quick fix I was thinking about was to store the salt along with the user table property, it might be called "salt", but that would lose the goal of having salt from the first place if it is too easy to find the salt from the database.

Can anyone advise this?

NOTE. I use either the Python built-in library ( hashlib ) or Bycrypt ( Cryptacular or Passlib )

+4
source share
3 answers

The quick fix I was thinking about was to save the salt along with the user table property

This is exactly what you are doing. Knowing salt does not really detract from their benefits:

  • Identical passwords in your database will have different hashes.
  • Rainbow tables will not work.
  • Brute force attacks that try to match any of your hashes will be slowed down.
+7
source

If you are using cryptacular.bcrypt.BCRYPTPasswordManager , you do not need to worry about salts. He takes care of creating and storing the hash salt.

Below you can see that the hash string is different for the same password. This means that salt has been used.

For ex:

 >>> import cryptacular.bcrypt >>> crypt = cryptacular.bcrypt.BCRYPTPasswordManager() >>> crypt.encode('aaa') '$2a$10$B0czYdLVHJG4x0HnEuVX2eF7T9m1UZKynw.gRCrq8S98z84msdxdi' >>> crypt.encode('aaa') '$2a$10$Ni7K.pQoal3irbGmREYojOYoi0lye/W0Okz7jqoynRJhW5OCi8Upu'
+1
source

There is no purpose for a password - just to avoid a simplified dictionary attack. TMHO in many applications there uses only one hash for all passwords.

For example, let them say: God, the sun and love are the common password. Any attacker can have a dictionary containing these words, and hash.

If instead of storing a hash (password) you store a hash (password + salt) (or a hash (salt + password)), you can invalidate this dictionary, because if your salt is "dza $ ^" é) "the probability that the dictionary contains "dza $ ^" é) àùgod, tends to be 0.

Changing the salt at each input can also be good practice (but I think it’s not so common), but you have to find how to get it in order to verify the password.

0
source

More articles:


All Articles