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.