But, your main thought, make the client pay something to make use of the servers bcrypt function made me think of an issue I was pondering a couple of years ago – how do you make a javascript based chat client talk across the open internet and ensure privacy. Unless the key is generated in the client, it will be seen when the source of the client is loaded on the initial web page.

I then researched and finally implemented something in which I got the client to compute an Asymmetric Key Pair, pass the Public Key to the server, who then encrypted a des key with it and passed it back to the client, who then encrypted his messages with it. The REAL problem in all of this was getting the client (browser) to computer the key pair – it was expensive and needed a special implementation technique (see http://www.chandlerfamily.org.uk/2010/06/the-making-of-mbchat-v3-part-1-introducing-non-structured-programming/)

What if you implement something like this

ACCOUNT CREATION
1) Client calculates Asymmetric key pair and sends public key to server
2) Server stores public key against that client’s account and generates a random des key which it encypts with the public key of the client
3) Client decrypts des key with his private key of the pair and uses the des key to symetrically encrypt password to go back to server for storage
4) Server bcrypts this password and adds it to the database.

USER LOGIN
1) Client creates a (MUST BE DIFFERENT) key pair and sends public key to server along with username
2) Server checks public key received IS NOT THE SAME AS BEFORE, or TOO MANY ATTEMPTS are being made too fast -it marks that it will ultimately reject the password
3) If the key is different, this gets stored, along with time of last access
4) Server generates random des key, encrypts with public key (even a repeated one) and sends back to client
5)Client decrypts with his private key and then encrypts his password with des key and sends back to server.
6) if server finds previous public key was not a fresh one, or too many requests are coming, it says the passwords don’t compare without even computing the bcrypt.
7) Otherwise it does the bcrypt and compare and returns the result of that comparison.

If you have the luxury of running native code on the client, then I think the best way would be to run a modified SRP: instead of deriving x=sha1(salt + sha1(username + “:” + password)), insert your expensive hash of choice there. Such as x=sha256(pbkdf2(hmac_sha256, username + “:” + password, salt, iters)).

Then the verifier (g^x % N stored on the server) is expensive for the attacker to try brute-forcing due to the cost of x, while it doesn’t consume server CPU at authentication time because it was precomputed. (Of course it consumes client CPU as it has to derive x from the given password.)

But if you’re writing a web app instead, I don’t know of any reliable JS SRP implementations, and doing crypto in JS is rather slow. I can bcrypt with 09 work on a virtual machine in under 100 ms, while doing the same in JS is 300ms (chrome 22) to 1100ms (ie9) on the bare metal. If anyone shows up using IE8, ouch. And that doesn’t even get into mobile devices.

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.

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

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.