Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse?

Question

Relevant XKCD

There are many sites on the Internet that require login information, and the only way to protect against password reusing is the "promise" that the passwords are hashed on the server, which is not always true.

So I wonder, how hard is to make a webpage that hashes passwords in the client computer (with Javascript), before sending them to the server, where they would be re-hashed? In theory this doesn't give any extra security, but in practice this can be used to protect against "rogue sites" that don't hash your password in the server.

Answer 1

I don't know why so many sites don't do it, but I know that it is possible and works well since I have done it already. The server sends a random salt string in the login page which gets appended to the password in javascript in the browser and the SHA1 hash of the result gets then submitted back to the server for verification.

Here is my SHA1 implementation in javascript, that you may use if you like:

function sha1(msg)
{
  function rotl(n,s) { return n<<s|n>>>32-s; };
  function tohex(i) { for(var h="", s=28;;s-=4) { h+=(i>>>s&0xf).toString(16); if(!s) return h; } };
  var H0=0x67452301, H1=0xEFCDAB89, H2=0x98BADCFE, H3=0x10325476, H4=0xC3D2E1F0, M=0x0ffffffff; 
  var i, t, W=new Array(80), ml=msg.length, wa=new Array();
  msg += fcc(0x80);
  while(msg.length%4) msg+=fcc(0);
  for(i=0;i<msg.length;i+=4) wa.push(msg.cca(i)<<24|msg.cca(i+1)<<16|msg.cca(i+2)<<8|msg.cca(i+3));
  while(wa.length%16!=14) wa.push(0);
  wa.push(ml>>>29),wa.push((ml<<3)&M);
  for( var bo=0;bo<wa.length;bo+=16 ) {
    for(i=0;i<16;i++) W[i]=wa[bo+i];
    for(i=16;i<=79;i++) W[i]=rotl(W[i-3]^W[i-8]^W[i-14]^W[i-16],1);
    var A=H0, B=H1, C=H2, D=H3, E=H4;
    for(i=0 ;i<=19;i++) t=(rotl(A,5)+(B&C|~B&D)+E+W[i]+0x5A827999)&M, E=D, D=C, C=rotl(B,30), B=A, A=t;
    for(i=20;i<=39;i++) t=(rotl(A,5)+(B^C^D)+E+W[i]+0x6ED9EBA1)&M, E=D, D=C, C=rotl(B,30), B=A, A=t;
    for(i=40;i<=59;i++) t=(rotl(A,5)+(B&C|B&D|C&D)+E+W[i]+0x8F1BBCDC)&M, E=D, D=C, C=rotl(B,30), B=A, A=t;
    for(i=60;i<=79;i++) t=(rotl(A,5)+(B^C^D)+E+W[i]+0xCA62C1D6)&M, E=D, D=C, C=rotl(B,30), B=A, A=t;
    H0=H0+A&M;H1=H1+B&M;H2=H2+C&M;H3=H3+D&M;H4=H4+E&M;
  }
  return tohex(H0)+tohex(H1)+tohex(H2)+tohex(H3)+tohex(H4);
}

This way you can of course also avoid to ever send the passwords over the net, even when the user chooses or changes his/her password: A random salt gets appended to the newly entered password in the browser and the hash of this gets transmitted to the server. If the password change is accepted the server needs to store the salt and the hash for the user account instead of the plain text password. The login page now uses two salts: the static one of the user account and a random one that is only valid for a single login attempt. The plain text password gets first hashed with the static user account salt and this hash is hashed again with the current login salt and this gets transmitted to the server.

Update: The response to this and other answers to this question shows that some further explanation might be helpful here:

What are the benefits of the suggested approach?

• It is meant to make it considerably harder to harvest passwords from the data that is transferred over the network, i.e. by using a sniffer. It does not make it impossible to obtain a weak password from the data that gets transferred but strong passwords are save against all attacks that are feasible today.
• It is easy to implement and requires no extra effort from the user, needs no special equipment on the users side and works with all browsers that support javascript. The users get a login page as they know it and as it is widely accepted.
• The clear text passwords never enter the web server which makes it much harder to obtain them in case the server or it's database gets compromised some day.
• It protects the passwords of all users of the website, whether they are aware of the problem or not.

How can it be attacked?

• It can of course be broken if the attacker is able to manipulate the the website and/or the javascript that is transferred to the user. The attacker can then simply remove the hashing to let the browser send the password in clear text and may do the hashing himself if he still wants to send the response back to the origin server. But if this happens much more is at stake then just the protection of reused passwords. I.e. the attacker can then as well spoof the entire website. One possible protection against this attack would be to use a secure transport protocol like SSL. While this would make the first 2 benefits obsolete since they can now be achieved already by the transport layer security it would still have the benefit that the plain text passwords never enter the web server.

Why is it secure

• The suggested approach uses a SHA1 cryptographic hash function together with a salt. While the SHA1 hash function is considered relatively weak (in theory) compared to hash functions that use more bits it is still entirely save against preimage attacks which would be required to obtain a unknown strong password from the data that gets transferred. There has been not a single successful preimage attack reported against SHA1 to this day on any hardware, not even against MD5 which is considered to be weaker then SHA1. There are reports of successful collision attacks but these are far less computing intensive than preimage attacks and and of no use at all here. Even if SHA1 would indeed become useless for this use case some day it would be no big problem to switch to another hash function in relatively short time but you can of course use already one of these from the beginning. The only disadvantage of longer hashes is that they also take longer to compute which can be a factor here since the hashing runs in javascript and you may want to use it also on less powerful devices like phones.
• The salt is a string of random data. I use 20 characters from a alphabet of 62 symbols [0-9a-zA-Z] which is 119 bits of random data that gets generated with a secure random generator. The salt protects the hash values against attacks with rainbow tables and all other forms of precomputed values which could be used to grab at least the weaker passwords from the network traffic with easily available computing power. Weak passwords are still vulnerable since they can be deduced from the hash and salt with dictionary attacks and brute force for relatively short passwords. But due the salt these attacks require considerable computing power for every attempt to find a single password.

Why is it not widely used?

• I think it's mostly because the users at large are not really aware of the problem and thus don't request more protection. They also won't see any immediate benefit which means a website can hardly gain some accountable advantage form protecting their users passwords this way.
• There is transport layer security which prevents against password sniffing and additionally allows to authenticate the server and protects the content against modification.

Answer 2

In theory this doesn't give any extra security, but in practice this can be used to protect against "rogue sites" that don't hash your password in the server.

How exactly does this protect you? It sounds like all you want to do is hash the hashed password which is sort of pointless. Because the hashed password would then become the password.

There are many sites on the Internet that require login information, and the only way to protect against password reusing is the "promise" that the passwords are hashed on the server, which is not always true.

How about not using the same password for more then one site. The reason websites hash the password in theory is to prevent access to your account if THEY are compromised. Using the same password for multiple websites is just stupid.

If you did use javascript, all the "hacker" would have to do is, use the same method on the hashed-hashed-passwords. Once you have the hashed information its just time it takes to compute the password->same hash in the database that is a factor preventing access to an account.

Answer 3

Why isn't it used? Because it's a lot of extra work for zero gain. Such a system would not be more secure. It might even be less secure because it gives the false impression of being more secure, leading users to adopt less secure practices (like password reuse, dictionary passwords, etc).

Answer 4

The solution is simpler than that. Client certificates. I create a client certificate on my machine. When I register with a website, we do a handshake using my client certificate and the server's certificate.

No passwords are exchanged and even if someone hacks the database all they'll have is the public key of my client certificate (which should be salted and encrypted by the server for an added level of security).

The client certificate can be stored on a smart card (and uploaded to a secure online vault using a master password).

The beauty of it all is it removes the concept of phishing away...you're never entering a password into a website, you're just handshaking with that website. All they get is your public key which is useless without a private key. The only susceptibility is finding a collision during a handshake and that would only work one time on a single website.

Microsoft tried to provide something like this in Windows with Cardspace and later submitted it as an open standard. OAuth is somewhat similar but it relies on an intermediated "issuing party". InfoCards on the other hand could be self issued. That's the real solution to the password problem...removing passwords altogether.

OAuth is a step in the right direction though.

Answer 5

It is definitely possible, and actually you do not need to wait for a website.

Have a look at SuperGenPass. It is a bookmarklet.

It simply recognizes passwords fields, concatenates what you type with the website domain, hash it, mangles it somewhat so as to get only "admitted" characters in the password, and only then is your hashed-password sent on the wire.

By using the site domain in the process, you thus get a unique password per site, even if you always reuse the same password.

It is not extremely secure (base64-MD5), but you perfectly distribute a sha-2 based implementation if you wished.

The only downside is if the domain change, in which case you'll need to ask the website to reset your password because you'll be unable to recover it by yourself... it does not happen often though, so I consider it an acceptable trade-off.

Answer 6

I like X4u's answer, but in my opinion something like it should be integrated into the browser/the html specification - as at the moment it's only half the answer.

Here's a problem I have as a user - I have no idea whether my password is going to be hashed at the other end when stored in the database. The lines between me and the server may well be encrypted but I have no idea what happens to my password once it reaches the destination - it maybe stored as plain text. The database admin guy may end up selling the database and before you know it the whole world knows your password.

Most users reuse passwords. Non technical people because they don't know any better. Technical people because once you get to the 15th password or so most people don't stand a chance of remembering them unless they write them down (Which we all know is also a bad idea).

If Chrome or IE or what ever it was I am using could tell me that a password box is instantly going to be client side hashed using a server generated salt and effectively sandbox the password itself - then I would know that a user could reuse a password with less risk. I'd still want the encrypted channels as well as I don't want any eaves dropping going on during transmission.

The user needs to know that their password is not even available to be sent to the server - only the hash. At present even using X4U's solution they have no way of knowing this is the case because you don't know if that technology is in use.

Answer 7

The best solution is (imo) a client side password manager. That way, you can generate a random string of characters as your password and you're not relying on the server to 'protect' you.

Answer 8

I think it's a good method to use when building something like a framework, CMS, forum software, etc., where you don't control the servers that it might be installed on. That is, YES, you should always recommend use of SSL for logins and logged-in activity, but some sites using your framework/cms won't have it, so they could still benefit from this.

As others have pointed out, the benefit here is NOT that a MITM attack couldn't allow someone else to log into this particular site as you, but rather that that attacker wouldn't then be able to use the same username/password combo to log into possibly dozens of other sites you might have accounts on.

Such a scheme should salt with either a random salt, or some combo of site-specific and username-specific salts, so that someone who gains the password can neither use it for the same username on other sites (even sites using the identical hashing scheme), nor against other users of the site site who might have the same password.

Others have suggested that users should create unique passwords for every single site they use, or use password managers. While this is sound advice in theory, we all know this is folly to rely on in the real world. The percentage of users who do either of these things is small and I doubt that will change any time soon.

So a javascript password hasher is kind of the least that a framework/cms developer can do to limit the damage of someone intercepting passwords in transit (which is easy over wifi networks these days) if both the site owner and the end users are being negligent about security (which they likely are).

Answer 9

Because it would add little to no value. The reason hashing is that if your database gets hacked, the hacker would not have a list of valid password, just hashes. Therefore they could not impersonate any user. Your system has no knowledge of the password.

Secure comes from SSL certificates plus some form of authentication. I want my users to supply a password so I can calculate the hash from it.

Also, the hashing algorithum would be on the server in a more secure area. Putting it on the client, it's pretty easy to get the source code for Javascript, even if its hidden referenced scripts files.