4 ms·
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 sev
by WA 15y ago
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.
- 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.