Comments for Hash Collisions

Comment on Can bcrypt’s computational expense be reduced on the server side? by Andres

Andres — Tue, 28 Jun 2011 18:47:12 +0000

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.

Comment on Can bcrypt’s computational expense be reduced on the server side? by Andres

Andres — Tue, 28 Jun 2011 17:22:57 +0000

This article is being disccussed on Hacker News. Be sure to check it out:

http://news.ycombinator.com/item?id=2705915

Comment on Can bcrypt’s computational expense be reduced on the server side? by Robin Message

Robin Message — Tue, 28 Jun 2011 16:24:47 +0000

> Account Log-in
> 6 The browser submits Turing’s username and bcrypted hash to SecureR.
> 7 SecureR directly compares the hash submitted by Turing with the one stored in his user record. If they match, account access is granted.

So, suppose I’ve stolen the password database of SecureR. Unfortunately, I can’t recover the password of the user. However, I only need the hash of it (which is stored in the database) to log in, so I don’t need to recover the password anyway.

This does protect against exposing the user’s password, so it’s not a total waste. An additional wrinkle:

You could store the hash of the bcrypted password in the database. The browser would submit the bcrypted password in 6, and the server would hash it in 7 before checking it. This makes recovering the password infeasible but logging in is cheap for the server, and the input to the hash function has high entropy, so it will still be hard to crack. At this point though, you need a security expert to evaluate it.