Hacker News Reader

Comment by Khao | Hacker News Reader

I have read this article and read the Wikipedia entry on bcrypt and I still cannot understand something. In this article it states that : "As computers get faster you can increase the work factor and the hash will get slower.". How can you make the algorithm slower over time and still be able to validate user passwords that were stored before you changed the speed? Could anyone enlighten me on this?

View on HN

I believe that the work factor is encoded with the hash, so bcrypt can identify which work factor to use.

Thanks for your answer. At first I though it didn't make sense because the hash should be one-way and bcrypt should not decrypt the hash or mess around with it other than comparing it with what the user entered but I have searched a bit more and found this post on stackoverflow that explains in detail : http://stackoverflow.com/questions/4443476/optimal-bcrypt-wo...

Your answer was right, it stores the work factor, the salt and the hash so that at any given time you can change the work factor and it will adjust in the database!

The easy way is to support the previous work factors and increase it next time the user logs in (since you'll have the password in plaintext in memory). Either way, bcrypt with a paltry work factor of 7 or 8 is orders of magnitude slower than md5 and sha. Jack that up to 12 or 13 and you're pretty much good to go for years, the only problem is the near 1-second processing time on semi-current hardware.

It's a hash function and, at least over an insecure connection, you should not be transferring the plaintext password from client to server so it's not guaranteed that you will have the plaintext password.

Assuming you're using a secure connection and you're willing to send plaintext passwords over it then yes, you could re-hash the password when a user logs in.

In any kind of scheme where all the server stores is some kind of hash of the password, how are you going to verify a password without sending the plaintext password to the server, so the server can compute the hash and compare against the stored hash?

You could do that with something called a Zero-knowledge password proof[1], of which SRP[2] is an example. As far as I know, SRP is patented. It is extremely clever, though.

[1] http://en.wikipedia.org/wiki/Zero-knowledge_password_proof [2] http://en.wikipedia.org/wiki/Secure_remote_password_protocol

To the best of my knowledge the SRP patents are not a big deal, and SRP is used in a number of commercial products. The bigger problem with SRP is that it's dangerous; it is difficult to screw bcrypt up, but it's very easy to screw SRP up; if you have to implement it yourself, dollars/donuts you're going to end up with an implementation that allows me to log in without a password.

I agree. I should just clarify that I'm all for bcrypt, having used it and recommended to friends/clients/employers. When I found out about SRP, I was researching on ways to do exactly what tzs asked, i.e., verifying a password without sending the plaintext (or plaintext-equivalent). In my case, the client had a login form that couldn't be placed behind SSL (don't ask why). Do you know of any solutions to this problem?

One possible option is challenge-response authentication. There a number of variations, but the simplest example is to hash both the hashed password and a nonce on both ends and check the resulting hash[1]. This means that the server only requires that the hashed password is stored, and the client never sends the password in plaintext as it generates the hash itself. As long as the nonce is unique each time, we can prevent replay attacks.

Various schemes introduce a client nonce and server nonce (to prevent man-in-the-middle attacks) or generate a shared secret nonce through methods similar to the Diffie-Hellman key exchange (so attackers can't work out the nonce).

[1] Ensure that h(h(passwd)+nonce) is equal on both ends where h(passwd) is either stored (server) or created by the user providing the plaintext password.

[2] http://en.wikipedia.org/wiki/Challenge-response_authenticati...

The goal of hashing the passwords is to not store them in plaintext in the database, in case the server is compromised. In your case, an attacker doesn't need the password, the hash is enough to login.

I suppose you mean "goal <...> is to not store them in plaintext"? I was confused there for a second.

Indeed, thanks. I fixed it.

It's rather obvious that we're talking about a system in which the client submits the clear-text password to the server, and of course that should be done over SSL.

The vast majority of site authentications (including many very large sites) use http, so their authentication code should be hashing and salting the password on the client-side and sending the result to the server for authentication. In this model, the site never actually has a plaintext copy of the password.

In this model, the server would receive the (unsalted) hash of the password when the password is set, and a salted hash for each login. At no point will the server ever have the plaintext password.

I describe the implementation details here:

http://loewald.com/blog/?p=1374

This is not a secure system. It is completely broken. The hash simply becomes the password when you do this. All an attacker needs to do is replay the hash and they're in. The "plaintext" is irrelevant, because an attacker doesn't need it.

Also, if you're storing the unsalted hash in your DB, your security is doubly broken. Someone who accesses your DB can more easily brute force the passwords (it looks like you're using a single salt rather than a per-user salt), and your scheme is vulnerable to rainbow attacks as well.

If you know the previous work factor of a hash, you could of course re-hash it New-Old factor times.

Here is an example:

https://gist.github.com/1051238

Reply on news.ycombinator.com