4 ms·
Is there any reason why you wouldn't use bcrypt + random, individual salt? Am I right in assuming that bcrypt would protect against brute-force attacks and salt
by coffeecheque 13y ago
Is there any reason why you wouldn't use bcrypt + random, individual salt? Am I right in assuming that bcrypt would protect against brute-force attacks and salt protects against pre-computed bcrypt rainbow tables? Or is the salt basically useless?
- tptacek 13y agobcrypt is already randomized, as is every other modern KDF. There is no such thing as a bcrypt rainbow table. Rainbow tables have never really mattered. Stop thinking about rainbow tables. You need to be using real KDFs to store passwords. Salted hashes are not real KDFs.
- coffeecheque 13y agoThanks very much for that explanation. I'm not a computer expert, but I'm endlessly fascinated by passwords and cracking. When it comes to picking passwords that humans can remember, what's your opinion on Diceware? Do five or six word passwords still stand up with the increases in computational power? http://world.std.com/~reinhold/diceware.html http://world.std.com/~reinhold/diceware.html
- tptacek 13y agoI think it's important to pick a password that isn't in a list, or likely to be 1-2 transformations away from being in a list, and it's important to use a longer password, but apart from that it shouldn't matter as long as you use a different password for each service, and as long as the apps you use use bcrypt or some other real KDF.
- javajosh 13y agoWould it be useful to check password hashes against well-known lists of passwords? If so, it sounds like a service would be doing pretty good if they: 1. Required >7 character passwords 2. That don't appear on (constantly updating) lists 3. Using a reasonable KDF (b/scrypt) Sound right?
- tptacek 13y agoThat sounds fine to me.