[Xylakant]

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.

[thirsteh]

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.

[Xylakant]

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.

[thirsteh]

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.

[stouset]

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.

[fabulist]

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.