5 ms·
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 se
by nonane 15y ago
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.
- tedunangst 15y agoMost 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.
- darrenkopp 15y agoI don't think he's talking about users... I think he's talking about high volume web services.
- nl 15y agoWebservices usually use signed requested[1][2] for security, not username/password pairs. [1] http://oauth.net/core/1.0/#signing_process http://oauth.net/core/1.0/#signing_process [2] http://en.wikipedia.org/wiki/WS-Security#Features http://en.wikipedia.org/wiki/WS-Security#Features
- chops 15y agoIt 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)
- cookingrobot 15y agoCould 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.
- mynegation 15y agoNo, you couldn't. Nothing prevents malicious client from "letting itself in", no matter whether password was correct or not.
- pixeloution 15y agobcrypt 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.
- falcolas 15y agoYour comparison is flawed - you're comparing GPU evaluation times for MD5 against CPU evaluation of bcrypt.
- pixeloution 15y agoThere 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)
- jat850 15y agoI'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.)
- tptacek 15y agoSeveral 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.
- deleted 15y ago[deleted]
- furyg3 15y agoI'm really interested into the longer answer! I'm sold on bcrypt but like to hear scaling stories :)
- moe 15y agoOne 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.
- domador 15y agoPlease, 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 http://news.ycombinator.com/item?id=2705915 (but my ideas have their own set of problems.)
- WA 15y agoAn 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.
- JoachimSchipper 15y agoThat 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.
- WA 15y agoThat might be a valid point. I just checked this: http://javascript-bcrypt.googlecode.com/hg/test.html http://javascript-bcrypt.googlecode.com/hg/test.html The initialization phase takes very long.
- owenmarshall 15y agoI 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...
- espo 15y agoIf 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.
- WA 15y agoRight. I just realize my approach is flawed ;)
- jules 15y agoWhat 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.
- roel_v 15y agoI 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.