Why is client-side hashing of a password so uncommon?

  • There are very few websites that hash the users password before submitting it to the server. Javascript doesn't even have support for SHA or other algorithms.

    But I can think of quite a few advantages, like protection against cross-site leaks or malicious admins, which SSL does not provide.

    So why is this practise so uncommon among websites?

    What advantages do you think there are to client side hashing of passwords?

    @TimLamballais A typical client can spend far more time on hashing than a server. So if you have a high performance implementation in the client (which rules out javascript in current browsers) you can use more expensive and thus stronger password hashes. It also means that the server never sees the password itself. Client side hashing is also a prerequisite for augmented PAKE protocols like SRP where impersonating the server doesn't give you access to the password.

    Javascript isn't really that slow anymore. Modern javascript engines have become so fast that they are on-par with compiled languages and recent additions like typed arrays provide the proper tools for the number-crunching required for cryptography.

    @TimLamballais One advantage would be that the server never sees my real password, and cannot possibly leak it (yes, they can still leak the hash, but it should be salted by the domainname, so useless for login to other sites). But for the largest advantage see my comment to Phillip's answer.

    A lot of people question whether any extra security is gained with this practice. One thing it does do is reduce risk. If you always hash or encrypt (I've seen steam/valve encrypt with a public key and I bet they are not decrypting) there is no chance of you ever having an embarrassing plaintext breech. No...it isn't any more secure but it isn't pointless

    WPA2-PSK uses client-side hashing of password for authentication.

  • paj28

    paj28 Correct answer

    5 years ago

    Inventor of JavaScript password hashing here

    Way back in 1998 I was building a Wiki, the first web site I'd built with a login system. There was no way I could afford hosting with SSL, but I was concerned about plaintext passwords going over the Internet. I'd read about CHAP (challenge hash authentication protocol) and realised I could implement it in JavaScript. I ended up publishing JavaScript MD5 as a standalone project and it has become the most popular open source I've developed. The wiki never got beyond alpha.

    Compared to SSL it has a number of weaknesses:

    • Only protects against passive eavesdropping. An active MITM can tamper with the JavaScript and disable hashing.
    • Server-side hashes become password equivalents. At least in the common implementation; there are variations that avoid this.
    • Captured hashes can be brute forced. It is theoretically possible to avoid this using JavaScript RSA.

    I've always stated these limitations up front. I used to periodically get flamed for them. But I maintain the original principle to this day: If you've not got SSL for whatever reason, this is better than plaintext passwords. In the early 2000s a number of large providers (most notably Yahoo!) used this for logins. They believed that SSL even just for logins would have too much overhead. I think they switched to SSL just for logins in 2006, and around 2011 when Firesheep was released, most providers switched to full SSL.

    So the short answer is: Client-side hashing is rare because people use SSL instead.

    There are still some potential benefits of client-side hashing:

    • Some software doesn't know if it will be deployed with SSL or not, so it makes some sense to include hashing. vBulletin was a common example of this.
    • Server relief - with computationally expensive hashes, it makes sense for the client to do some of the work. See this question.
    • Malicious admins or compromised server - client-side hashing can prevent them from seeing plaintext passwords. This is usually dismissed because they could modify the JavaScript and disable hashing. But in fairness, that action increases their chances of being detected, so there is some merit to this.

    Ultimately though these benefits are minor, and add a lot of complexity - there's a real risk that you'll introduce a more serious vulnerability in your attempt to improve security. And for people who want more security than password, multi-factor authentication is a better solution.

    So the second short answer is: because multi-factor authentication provides more security than client-side password hashing.

    What if, _the server has been compromised_ by a cracker and he'd like to gather plain passwords from clients to use them at other places? No safeguard but client-side hashing. Why must we force clients to trust the server?

    @КонстантинВан - please refer to the "compromised server" part of the answer

    Another drawback of client side hashing is that you cannot enforce password policy on the server. Basically you cannot validate that the user selected password is strong enough

    @Michael That's a good thing in my opinion, since password policies on most servers are ridiculous. Many password characters are forbidden for no reason.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM