Hacker News Reader

Comment by Spittie | Hacker News Reader

Question: that article suggest to hash passwords client side too. This has any security advantages?

The only one that I can think of is that an eventual MITM can't sniff your password, and then try to reuse it with other sites (as he only has an hash specific for a site, and not your password). Is that all?

"If you are worried about the computational burden, but still want to use key stretching in a web application, consider running the key stretching algorithm in the user's browser with JavaScript." make it sounds like I can use a lighter hash-solution server-side if I use key stretching client-side (at least to me, non native here so probably I'm just reading that wrong).

View on HN

It gives some level of protection against buggy server-side code leaking the plain-text password. I remember a case where a site logged all request information (including the plain-text password) directly to a log file. Oops!

IMO Hashing on the client side is a terrible idea. There is now no way for the application to check the complexity of the password on the server side. Relying on client side controls to do the same is almost useless.

Why do you think it's useless? Not transmitting the password in plain text is clearly a win, and you can do whatever checks you need on the client side just as easily. (If a user wants to fool whatever checks you have, they can do that whether or not you have server-side checks--it happens all the time.)

It's fairly useless: If an attacker can sniff your connection he can just submit the encrypted password he sniffed to the server. The only win you have is that the attacker can't see the password itself, a potential bonus when people reuse passwords.

However, if you can sniff the connection you can probably alter it and inject javascript that submits the clear-text password to the attacker.

We are just talking about scrambling the password. You would still be using e.g. SSL/TLS or TLS-SRP for the transport. There's nothing "useless" about it.

Well, useless as in "added implementation complexity and no gain". It won't hurt much either, but you could be spending your time better elsewhere, for example in tuning your SSL/TLS-setup.

I agree with you about SSL, client-side hashing seems like a solution for a very mature website with clientèle who strongly value their privacy. Something like LavaBit comes to mind (RIP). But "useless" is too strong a word. It is really trivial to use stolen credentials on other services, and effective to boot. But by hashing on the client side in addition to the server, you "double" the amount of effort required to perform the attack.

No. There's absolutely a gain. A big one, too. The main reason it isn't done today is not that it isn't useful, but that it's too slow to run e.g. bcrypt on the client without native browser APIs. WebCrypto will change that by adding PBKDF2 as a module accessible from JavaScript.

The main reason we encourage people to use key stretching algorithms on the server is that, if an attacker gets access to a database of password digests that aren't very strong, they can trivially be reversed.

Doing this key stretching or "password scrambling" on the client side simply moves the processing burden from the server to the client. There is nothing less secure or less useful about it.

There is, if you don't again hash the passwords on the server. This is why new password-hashing proposals like [Catena](http://eprint.iacr.org/2013/525.pdf) include an official "server relief" mode where the majority of the hashing is done on the client side, but there's still a final server-side transformation step.

Until such time as these things are readily available, recommending that people do client-side hashing is absolutely going to result in trivially poor implementations.

You might want to consider that if these problems were as trivial as you seem to believe, there would already exist a library vetted by cryptographers to do exactly that.

Password complexity is not a critical validation. The client-side code could easily perform the same validation before hashing. If someone hacked the client-side code and intentionally disabled the validation, then they could submit a weaker password, and that's not a big deal. It's a huge win if the plaintext password doesn't leave the browser.

Reply on news.ycombinator.com