[coffeecheque]

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]

bcrypt 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]

Thanks 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

[tptacek]

I 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]

Would 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]

That sounds fine to me.