Proper way to send username and password from client to server

HttpAuthenticationHttpsCredentials

Http Problem Overview


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

Http Solutions


Solution 1 - Http

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

Solution 2 - Http

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.

Solution 3 - Http

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionSundayMondayView Question on Stackoverflow
Solution 1 - HttpJan KrügerView Answer on Stackoverflow
Solution 2 - HttpGreg HewgillView Answer on Stackoverflow
Solution 3 - HttpDave LView Answer on Stackoverflow