48

This question is not language specific. I'm curious how to properly send username and password from a website login form to a server.

My guess is to hash the password, put username/password in the POST body and send it over HTTPS. What's a better way?

For good measure I'll mention a less than ideal method:

http://www.somesite.com/login?un=myplaintextusername&pw=myplaintextpassword
Amit Joshi
  • 12,434
  • 18
  • 59
  • 118
SundayMonday
  • 17,607
  • 27
  • 94
  • 151

3 Answers3

69

The important parts are that you transmit the form data in the POST body (that way it's not cached anywhere, nor normally stored in any logfiles) and use HTTPS (that way, if you have a good SSL/TLS certificate, nobody can sniff out the password from observing your network traffic). If you do that, there is no big extra benefit in hashing the password, at least not during the transmission.

Why do people talk about hashing passwords, then? Because normally you don't want to store the user's password in plaintext form in your server-side database (otherwise the impact of a compromised server is even worse than it would be otherwise). Instead, you usually store a salted/hashed form, and then apply the same salt/hash to the password received via the form data, so that you can compare the two.

For more information on salting, see http://en.wikipedia.org/wiki/Salt_(cryptography) (and the links there).

Jan Krüger
  • 15,896
  • 3
  • 54
  • 50
  • 4
    ^Coming from a developer, I wish someone had put it in the same words as you did...when I was learning to develop apps for the first time in the past. Excellent! :) – Imdad Jan 05 '19 at 21:04
10

If you're using HTTPS, then you can send the name and password in a POST body which will be secure from eavesdroppers (assuming you trust SSL). You don't need to hash the password, if you do then the password hash is just as useful as the password itself, so it doesn't buy you anything.

A more important question is how you store the password on the server side. Storing a hashed password is only acceptable if you use a good algorithm such as scrypt. But that's still not as good as an advanced protocol such as SRP.

Greg Hewgill
  • 828,234
  • 170
  • 1,097
  • 1,237
  • Been doing web development for 4 years and worked at a few different companies and somehow have never heard of SRP... Read that Wikipedia article and that's awesome, why isn't this something that's talked about/used more? – nixin72 Sep 21 '20 at 03:17
  • Sending hashed passwords has the benefit that an attacker behind a compromised server can't see the password you are using (which might be one that has been used elsewhere). Although in an ideal world no one would ever use the same password twice, this would just add an additional layer of security. – xdevs23 Mar 22 '21 at 17:34
6

You should always use HTTPS and avoid homebrewed code. SSL will take care of hashing & encryption. That is the ONLY secure method.

Also ensure you're hashing passwords on the server end and storing the hash, not the original password. Then compare the hashes to check logins. This will prevent attackers reading plaintext passwords straight out of your db if its compromised.

Dave L
  • 752
  • 3
  • 10
  • So you are saying that no chap on this planet could think of a more secure encryption/hashing technique than what the blokes over at IETF came up with making TLS? – Xbox One Mar 01 '21 at 22:07