Hacker News Reader

Comment by nonane | Hacker News Reader

The article claims it takes bcrypt 0.3 seconds to hash a 4 char password on a laptop.

How does a server authenticate users in high volume with bcrypt? ~0.25 secs per auth request might warrant having a separate server just for authentication.

View on HN

Several of the largest sites in the world have scaled bcrypt. There are longer answers as to why this is not a big deal, but if it helps to kill the red herring that bcrypt might not scale: Twitter uses it.

I'm really interested into the longer answer!

I'm sold on bcrypt but like to hear scaling stories :)

One possible, slightly longer, answer would be that "login" is a relatively rare operation in the grand scheme of things.

Users (usually) need to login only once per session. And on sites that have the little "Remember me"-tickbox a session may very well last for days or even months.

Please, please, share the long answer! (or one of them, at least...)

I would think that using bcrypt for authentication would not only consume more server CPU power, but would also open the door to denial-of-service attacks (if crackers attempted brute-force attacks on the log-in system). Clearly "use bcrypt" is just part of the answer...

I had some thoughts on a way to deal with this:

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

(but my ideas have their own set of problems.)

It depends on the work factor. On my dev server (a pretty old machine), with a work factor of 7, it's about 300 time slower than md5 (about 10ms per bcrypt hash). That's still plenty fast, and much more secure. Bump it to a work factor of 9, and I'm looking at about 1000 times slower (or getting close to 40 ms per hash).

Part of its beauty is you can adjust the work factor to match your hardware speed requirements.

If you really want ultra-secure, a work factor is 13 is getting pretty slow (about half a second per hash on my crappy machine), and yeah, that might justify an authentication server.

(note: my tests were not exhaustive)

Could you design a system where the hard work happens on the client side? For ex, the server sends the client a secret encrypted with the bcrypt hash.. and then the client machine spends a couple seconds working on it and sends back the response. It might allow for a huge work factor without impacting the server.

No, you couldn't. Nothing prevents malicious client from "letting itself in", no matter whether password was correct or not.

bcrypt at 10ms only being 300 times slower would indicate you can only try 30,000 MD5 hashes per second -- which is incorrect. Using a GPU based cracker on a current generation top-end video card you can calculate over 300 million per second.

Bcrypt at 10ms is 3 million times slower, not 300 times.

Your comparison is flawed - you're comparing GPU evaluation times for MD5 against CPU evaluation of bcrypt.

There is no such thing as a GPU based bcrypt hasher because it woudln't be - from my understanding - any faster then a CPU based one. Not all calculations are able to be sped up through the use of a GPU.

So I'm comparing the fastest you can do bcrypt hashes (100 a sec at that work factor) vs the fastest you can do MD5 hashes (250 million per second)

Most of your traffic should be coming from people with logged in cookies. If you make people enter their password on every page, you won't have to worry about high volume. :)

Note that bcrypt is basically insensitive to length of password. 4 chars, 8 chars, 32 chars, all take the same amount of time. And it's tunable. You could go down to only 0.01s per hash and still be a million times slower than plain MD5.

I don't think he's talking about users... I think he's talking about high volume web services.

Webservices usually use signed requested[1][2] for security, not username/password pairs.

[1] http://oauth.net/core/1.0/#signing_process

[2] http://en.wikipedia.org/wiki/WS-Security#Features

I'm in the process of writing some code that is hitting these very scenarios and characteristics right now. The metrics we put on the API call showed a remarkable spike when we switched from plaintext (in development mode) to bcrypt hashes.

However, after logging in and establishing a session, there's really no impact to the user. We were content to trade the speed of lesser hashing algorithms for the security offered using bcrypt. The only noticeable difference is that our login process went from near-instantaneous to a marginal, but noticeable delay, on login.

(The same delay can be noted when setting new passwords.)

I guess by the time there are several users per second just authenticating, the $200 for a GPU that can boost hash performance 100x won't be the problem any more.

An idea would be to use a JavaScript implementation of bcrypt to let clients do the math themselves and just send the encrypted password via HTTPS. This has several advantages. One being that the server-side performance is reduced heavily. Another one is that a password never shows up on the server in plaintext ever.

Disadvantage: Clients need to have JavaScript enabled.

If you are doing this, then the hash IS the password. That means if someone steals your database, the could log in as all of your users just by tweaking the client-side JavaScript with grease-monkey or similar.

What if you use a cheaper hash function (e.g. bcrypt with a lower work factor) on the server? The bcrypt hash is the password, but a very long one compared to the password that the user entered, so presumably it is very expensive to brute force even with a relatively cheap hash function.

Right. I just realize my approach is flawed ;)

That doesn't work. Among other issues, Javascript is so much slower than C or CUDA at such tasks (no native integers!) that the client is going to take forever to calculate a sufficiently-hard hash.

That might be a valid point. I just checked this: http://javascript-bcrypt.googlecode.com/hg/test.html The initialization phase takes very long.

I think the most significant issue is that JS on the client is an absolute minefield for cryptography. Apart from the speed issues, it's impossible to secure...

Reply on news.ycombinator.com