Robin, Yes, if an attacker obtained the password database, they could use the password hashes to log in with any particular user's account. They wouldn't need

Robin, Yes, if an attacker obtained the password database, they could use the password hashes to log in with any particular user's account. They wouldn't need to know that user's plaintext password. Like you, I'd also thought about storing a second-level hash (a hash of the bcrypt hash). However, I didn't mention it because I don't currently understand the complexity of hash functions well enough. There are at least two issues that come to mind regarding the complexity of the second-level hash function: 1) If we used MD5 or SHA-1, would this cause the same problem Coda Hale warned against? A bcrypt hash would likely be longer and more complex than a typical user-defined 6 character password. Could a cracker feasibly produce the MD5 hashes for all the strings as long as a bcrypt hash? (I don't know how much slower MD5 gets with each additional input character, or how much slower it gets to produce MD5 hashes for all the strings of a given length.) 2) If we used bcrypt itself as a 2nd-level hash, wouldn't that cause the same problem I was trying to avoid (running bcrypt at log-in time)? Maybe this 2nd-level bcrypt hash could be configured to be less computationally expensive that the 1st-level hash (the one used on a user's plaintext password). Thus it'd be moderately inexpensive to verify a user's password, but more expensive to crack it (since the input string the password cracker is trying to find is a bcrypt hash, not a traditional, weak user-selected password). Like you said, I need a security expert (or several) to look into this. Thank you for your feedback.