59

I understand why the password should be salted and hashed before being saved into the database, but my question is if it needs to be hashed on the browser side or just sending plain-text password over HTTPS is considered to be secure.

If it is ok, is there any document which I can use to prove to my client that the system is secure? If it's not, what are the best practices?

Vilican
  • 2,703
  • 8
  • 21
  • 35
user96738
  • 599
  • 1
  • 4
  • 3
  • The answers to http://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side?rq=1 will help you explain to your client the pros and cons of hashing on one side or the other. – schroeder Jan 13 '16 at 00:22

3 Answers3

69

It is standard practice to send "plaintext" passwords over HTTPS. The passwords are ultimately not plaintext, since the client-server communication is encrypted as per TLS.

Encrypting the password before sending it in HTTPS doesn't accomplish much: if the attacker got their hands on the encrypted password they could simply use it as if it were the actual password, the server wouldn't know the difference. The only advantage it would provide is protecting users that use the same password for multiple sites, but it wouldn't make your site any safer.

Buffalo5ix
  • 2,636
  • 12
  • 18
  • 3
    Challenge-response also protects against replay attacks on the same service. – Ben Voigt Jan 14 '16 at 03:16
  • 7
    "The only advantage it would provide is protecting users that use the same password for multiple services." That could be [more than half](https://nakedsecurity.sophos.com/2013/04/23/users-same-password-most-websites/) of Internet users. – joeytwiddle Jan 25 '17 at 04:12
  • input of `type="password"` or`type="text"` is only about obfuscation.. Right? No matter HTTP or HTTPS, having type "password" vs "text" only means that you get obfuscation, the inability to copy paste from the field and that's it FTMP. Over HTTPS, every pice of anything is encrypted as a whole, so to use JavaScript to hash or encrypt that field will be overkill in most scenarios. otherwise, on it's own, the `type="password"` of an input field only provides dots (a visual representation of each character) for obfuscation and some basic interaction restrictions. – Eric Bishard Dec 27 '18 at 18:14
11

Sending passwords from the browser to the web server over HTTPS is standard practice. The password is encrypted by virtue of HTTPS as it is sent. See https://stackoverflow.com/questions/962187/plain-text-password-over-https

Community
  • 1
mti2935
  • 19,868
  • 2
  • 45
  • 64
7

When a user types a password in an HTML <input type=password ...> field it will normally be sent to the server as-is, i.e. without any hashing or salting. This is why this should never be done without HTTPS.

But if your HTTPS is solid this should be OK. It is what most web applications do.

Mark Koek
  • 1,311
  • 1
  • 8
  • 16