Hacker News Reader

Comment by WA | Hacker News Reader

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.

View on HN

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