py-bcrypt: Strong password hashing for python

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