3 ms·
That's just not true. To oversimplify a bit, let's say BCrypt is a function b(data, cost) that returns a hash. Right now, I have b(password, c1) = hash_a store
by smanek 15y ago
That's just not true. To oversimplify a bit, let's say BCrypt is a function b(data, cost) that returns a hash.
Right now, I have b(password, c1) = hash_a stored in my database. To increase the cost to c1+c2, I just replace that with b(hash_a, c2) = hash_b in my database. To verify a user's login, I just compute b(b(password, c1), c2) and compare it to the hash_b I have stored.
Am I missing anything?
- tedunangst 15y agoYes. That's not how bcrypt really works.
- smanek 15y agoI've read the usenix paper, and I'm reasonably sure I'm right. Care to elaborate on what I'm mistaken about? I (and a few other people I've talked to about schemes isomorphic to this about) may learn something new :-D
- tedunangst 15y agoOK, so you can chain bcrypt in theory, but if you look at the API and how it stores rounds/salt, I don't think you'll enjoy implementing the code to do so. You can't just store hash_b, you'll need to store hash_a too. It's not worth it. Basically, the assumption that bcrypt is just a function that returns a hash oversimplifies the detail of how salt is stored in practice.
- tptacek 15y agoI wrote a comment to the effect of "you can just chain bcrypt" but deleted it because I didn't want to wade into exactly this tarpit. If a client asked me how to upgrade the cost of their password hashes, I'd probably tell them to validate incoming plaintext and then create a fresh hash. I agree: this is not a big deal in practice. bcrypt with a cost factor of 10 is so much slower than SHA1 that this is just not going to be an issue.
- zcid 15y agoOr you can wait until the user signs in again and create hash_b at login with the plaintext password after you validate it against hash_a. I believe that is how the bcrypt documentation recommends you do it.
- VMG 15y agoThat is much less preferable though.