1

People are reusing passwords all the time, and with many sites accepting email addresses as logins, a stolen password can potentially unlock many accounts. So why not just hash the password locally via javascript and send the hashed password to the server(via SSL obviously) which then again hashes it, before saving it in its database. This would:

1:

Show security to concerned users, that their passwords are at least once hashed(by looking at the JS code), meaning their passwords are somewhat safe in any case.

2:

In the case of a stolen private key, decrypted captured communications between clients and servers would only reveal a hashed password. This would provide access to the corrupted service, but since the password is already hashed(and seeded with the site name or whatever) it can not be used to enter any other websites with email+password unless the hash is broken.

3:

In the case of stealing the password database, the server side hash AND the client side hash would have to be "reversed" to reveal the true password.

Now I am aware that these 3 cases are somewhat rare, however they are not far-fetched imho, since password databases get stolen, private keys are leaked and hash algorithms become outdated(see SHAttered). Now I know argument 3 isn't particularly strong, since passwords are hashed many times over anyway, but nevertheless my question:

Why isn't this best practice? Am I overseeing any drawbacks? Is this already implemented somewhere?

Community
  • 1
jaaq
  • 125
  • 4
  • 1
    If you're doing that, then noone really cares about the original password since only the hash needs to be sent to the server. The only thing that it would make difficult is stealing the password to use against other services, but this can be prevented by avoiding password reuse. – multithr3at3d Apr 24 '17 at 18:05
  • 1
    there's no reason concerned users couldn't implement this themselves if they saw a need... – dandavis Apr 24 '17 at 22:32

2 Answers2

2

Hashing the passwords on the client would at best do nothing, and at worst make users doubt your applications security. As far as the server is concerned, the client hashed passwords are effectively the cleartext passwords. See my answers to your individual questions.

  1. No, it does not. It just shows that it has been hashed in the browser. To the user, it does not mean that the password are hashed yet again on the server. If I saw this, I would assume that the hashing is being done only in the browser, and would assume the application is not secure.

  2. I assume you mean private key to the SSL certificate. If this has been stolen, there are much larger issues at stake. With the certificate information leaked, someone can successfully impersonate your web server, which means that none of the downloaded content can be trusted. The client-side scripts can simply snatch the passwords before they are encrypted.

  3. No, they would only need to crack the hashes obtained from the server. Again, as far as the server is concerned, the client-hashed password is the cleartext.

Dan Landberg
  • 3,312
  • 12
  • 17
  • Yeah, I know from the servers point of view it makes no sense. Obviously. But from a users point of view, he could(not should) reuse his password for all sites he uses and would not have to change it because one site got hacked.. – jaaq Apr 25 '17 at 15:43
0

As korockinout13 said, in many cases, only the hash is needed and not the plaintext password.

This is an old question of which has been discussed quite a lot. For much more information see Should I hash the password before sending it to the server side?.

user
  • 7,670
  • 2
  • 30
  • 54
valkyrix
  • 81
  • 5