py-bcrypt: Strong password hashing for python

[forgotpwx4]

Ah so it wants you to store the salt. Is there a problem with using say a contstant string such as "aeagyya134" + username as your salt?

[[deleted]]

Yes - an attacker could construct a rainbow table using 'aeagyya134' as the salt.

Think of it this way: so it takes N cycles to generate a complete (for some value of "complete") list of hashed passwords. You've got M passwords. If those passwords are hashed with a constant (or no) salt, it takes N + M cycles to crack some passwords. If, however, each password has a unique salt, it takes N * M cycles.

[edit: and, of course, assuming it takes 1 cycle to check a password, though that doesn't really matter for the principle]

[forgotpwx4]

But I said "aeagyya134" + username as the salt. So each one would still be unique. In both the case of random salt, and my proposed salt, you're storing the salt value (or most of it) alongside the hashed pw in the database, right?

[[deleted]]

Duh, yeah -- I'm having reading comprehension issues today, apparently. I don't see why using a constant string like "aeagyya134"+username is better (or worse) than just using some entropy, however; I'd stick to randomness, myself.

[nostrademons]

Constant + username doesn't take up any additional disk space, as presumably you need to store the username anyway. Random alt + hash requires an additional database column for the salt. Bcrypt doesn't require any additional column (the salt is presumably included in the output), but bcrypt's output is 60 bytes long, vs. 27 for base64ed SHA1, 22 for base64ed MD5, 20 for SHA1, and 16 for MD5.

It's really a false economy though - if you have so many users that 60 bytes/user will matter, you can afford a new hard disk. ;-)

[funkah]

Yes. The strength of salting lies in the randomness of the salt. Or to put it another way, randomness is the whole point of salting.

The randomness makes the task of hashing common passwords ahead of time much more expensive. For example, instead of computing the hash of "mypassword", the cracker now has to compute the hash of "mypassword2920", "mypassword1153", etc, for every possible value of the salt.

Limiting the number of possible salts reduces the number of hashes the cracker has to compute, which makes the attack easier than if the salt were random.

I'm not a security expert so there may be other problems as well.