50

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.

Improve this question
16
  • 19
    a hashed password sent in the clear is no better than a password sent in the clear if the server is just comparing hashes, man in the middle attacks love this kind of "security"
    – user7519
    May 17, 2011 at 21:14
  • 3
    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.
    – Dean Harding
    May 17, 2011 at 22:20
  • 3
    @Jarrod - it sounds to me, though, like different web sites using different client-side hashing algorithms would prevent the attack described by that comic. One widely re-used password becomes many different passwords through those differing hash algorithms. That client-side hash calculation doesn't prevent other kinds of security being applied - such as sending the hash through a secure connection.
    – user8709
    May 17, 2011 at 22:26
  • 2
    @Steve314 my point is anything on the client is compromised by default. You can hash and hash and hash, if it is being done on the client and being passed back and forth to the server in the clear it is just mathematical masturbation at that point. I had to fix a system I inherited, that was designed the exact way you and the OP describe, it was constantly being hacked by teenagers with Wireshark. We only locked it down when we put in REAL encryption and encrypted and signed all the payloads to and from the server, the account manipulation stopped and never happened again after that.
    – user7519
    May 18, 2011 at 16:27
  • 5
    It sounds like your plan for protecting yourself against rogue sites is to ask the rogue sites to set up better security. ?
    – pc1oad1etter
    Mar 9, 2012 at 16:15

8 Answers 8

Reset to default
48

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).

Improve this answer
7
  • 3
    This is the best answer so far.
    – user7519
    May 18, 2011 at 1:17
  • 1
    It's like Blu-Ray and DVD encryption. It doesn't even require a Key to unlock. The only "protection" it provided was that when DVDs first came out it cost more to buy a disc to copy it to than to buy a full copy of the movie. Of course now you can buy a dvd for a dollar and even more is the fact that the keys are public knowledge now. Same is happening with Blu-Ray
    – Michael Brown
    May 18, 2011 at 4:07
  • 2
    I think hashing a password client-side does add security. If I'm listening in, I can only see your hash, not your password. If the server sends a challenge (as it should) the hash is not even reusable.
    – Andomar
    Jun 14, 2012 at 9:13
  • 2
    I think x4u's approach may very well be appropriate for some applications where security requirements are somewhere between transmitting passwords on the wire and using certificates. I think some of the nay sayers are overlooking that the hashing of the password before it goes on the wire is done in addition to the standard server side credential handling. So the question is this: Does x4u's proposal improve security in the transmission-of-password-on-the-wire-scenario or not. I say it does. The key to realizing this lies in the usage of per-password salts.
    – LOAS
    Jul 23, 2013 at 9:19
  • 6
    The correct way to prevent MITM attacks is end-to-end encryption. TLS (https) exists: use it. Don't invent your own crypto schemes.
    – Rein Henrichs
    Jul 24, 2013 at 17:48
14

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.

Improve this answer
12
  • 1
    If your browser always hashes it the same way, then yes your hash can be used as a password everywhere else. But what if browsers assigned a salt based on the site (maybe the domain?) before hashing and sending that to the site? I think it's an interesting idea.
    – Tesserex
    May 17, 2011 at 14:43
  • 2
    if it is on the client it is compromised, any salt on the client is in plain view, this is an illogical question. if you don't understand @Ramhound's answer you should not be writing code that needs to be secure, and start reading up on security and cryptography from the beginning.
    – user7519
    May 17, 2011 at 16:52
  • 3
    When you are quoting the original poster, please format the text as such (select the text and use the quote icon just above the editor)
    – Marjan Venema
    May 17, 2011 at 18:19
  • 1
    Jarrod, please follow your own advice and get a bit informed yourself before you make ridiculous claims. A man in the middle attack is useless against secure hash functions with reasonable salt length. And my suggestion is in no way 'security by obscurity', it is actually safe based on what is currently known and accepted by the experts in this field and it is used the same way in many protocols. It is not my invention, I just applied a well understood procedure to a website login. Your false assumptions don't gain any substance by the fact that they are obviously shared by many others too.
    – x4u
    May 17, 2011 at 21:06
  • 3
    If the salt is known by the client and it is sent in the clear from a server, anything in the middle knows it as well. Never said, I needed to undo the hash, if you know the salt on the client, then isn't secure.
    – user7519
    May 18, 2011 at 1:11
11

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.

Improve this answer
2
  • 3
    This is the best answer. You should encrypt at the transport layer. Without doing that, the rest is not secure. Yes, you could write an encryption function... but that function would be visible to the (malicious) end users. Use SSL.
    – pc1oad1etter
    Mar 9, 2012 at 16:14
  • The security of a hashing algorithm shouldn't be dependent on whether it's secret. Hashing algorithms for security should be one-way functions: even if you have the code, it's hard to undo it. On the contrary, you should use a well-known hash library designed just for passwords. If it's not well-known, it's almost certainly buggy or mispurposed.
    – leewz
    Nov 6, 2018 at 17:07
10

most replies here seem to completely miss the point of client-side password hashing.

the point is not to secure access to the server that you are logging into, since intercepting a hash is no more secure than intercepting a plain text password.

the point is really to secure the user's password, which is usually far more valuable than individual site login access since most users will reuse their password for multiple sites (they shouldn't but the reality is that they do so it should not be waved off).

ssl is great for protecting against mitm attacks, but if a login application is compromised on the server, ssl won't protect your users. if someone has maliciously gained access to a web server, they will likely be able to intercept passwords in plain text because in most cases passwords are only hashed by a script on the server. then the attacker can try those passwords on other (usually more valuable) sites using similar usernames.

security is defense in depth, and client-side hashing simply adds another layer. remember that while protecting access to your own site is important, protecting the secrecy of the passwords of your users is far more important because of password reuse on other sites.

Improve this answer
5
  • it's probably more of a comment than an answer (apologies for not figuring out how to add to the accepted answer comment thread), and even though my point is shared in the accepted answer, it apparently wasn't clear enough since replies to it seem to brush it off still. thanks for the feedback
    – crutchy
    Aug 1, 2016 at 12:34
  • @Frank the accepted answer borders on being too long to bother reading. it goes into way too much detail of how this can be implemented and skims over benefits towards the end. Having a TL;DR in a different answer is beneficial.
    – Jules
    Aug 1, 2016 at 19:55
  • 2
    @Jules: That's why editing exists.
    – Robert Harvey
    Aug 2, 2016 at 15:20
  • A string of numeric character (hash) that gets stored in the clear is not better than a string of alpha-numeric characters that gets stored in the clear. What part of this do people not want to acknowledge. This is all just obfuscation and misdirection and overly complex mathematical masturbation that is in no way "secure".
    – user7519
    Sep 7, 2018 at 18:43
  • 1
    @JarrodRoberson I think you are confusing no more secure with insecure? If MITM happens, access to the site is already given up, isn't it? Unless you use client-certificate instead of password, which would be overly complex for ordinary users. The way I see it, client-side hashing prevents the same password being compromised on other sites, assuming each hashing algorithm is unique. It may not be more secure, but it's not less secure in any way either? So why do you push so hard on this? I came across this from meta, and this is the best answer I see so far.
    – zypA13510
    Sep 19, 2018 at 1:55
7

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.

Improve this answer
1
  • 5
    While client certificates are a reasonable approach for some use cases, they are not something that can be added easily to a website login. They require a great deal of cooperation from the users and depend on how secure the users private key is. The usage of a private key can be either secure or convenient but not both at the same time.
    – x4u
    May 17, 2011 at 20:13
2

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.

Improve this answer
8
  • This is what I was thinking when I read the question; it's practically useless for sites to do their own client-side hashing, but a browser extension that does it (using some salt based on the domain) would effectively nullify the risks associated with password reuse. Of course, the fun part comes when you try to log in from another machine...
    – Aaronaught
    May 17, 2011 at 23:32
  • 3
    this isn't anymore secure than any other scheme that passs the password in the clear. It makes the password unique but it still isn't encrypted, but if I have a server in the middle, I can just grab the complicated but still clear password and use it as much as I want, it isn't changing. A hash isn't some magic bullet, it isn't even encryption, they are called cryptographic hashes, but that doesn't mean they are encryption. Doesn't matter if my password is password and or an SHA-256 of password with some salt that is know to the client, a man in the middle attach can capture it.
    – user7519
    May 18, 2011 at 1:17
  • @Jarrod Roberson: you can use the password of course, but you cannot reuse it for another of my accounts, which is the point. Therefore, if one of the website I connect on got his password base stolen, and they stored them in the clear, then my other accounts are safe.
    – Matthieu M.
    May 18, 2011 at 7:00
  • @Aaronaught: that is where it shines actually. Since the password sent is derived purely from the website domain you log on and a master password of your choice, you can login from any computer (and browser) as long as you have the bookmarklet. This is why it's somewhat more comfortable than a certificate.
    – Matthieu M.
    May 18, 2011 at 7:02
  • 7
    @Jarrod: This isn't a security measure for the site, it's a security measure for the user. If everybody used a scheme like this, password reuse would be a non-issue. A MITM scheme could use the client-hashed password to gain access to that site, but only that site. That's where the improvement lies. Ordinarily you'd expect to be able to gain access to a lot of accounts by simply cracking one password, because that password is likely to be reused; in this case, the cracked password is practically guaranteed to only be valid for the site or database it was found in.
    – Aaronaught
    May 18, 2011 at 22:29
0

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 as a user I 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.

Improve this answer
1
  • 1
    it is integrated into the browser look up digest authentication and you'll see the back-and-forth steps taken in http to get a password hashed, with extra info, and verified on the server.
    – gbjbaanb
    Aug 1, 2016 at 11:28
-1

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).

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.