4

Sending plain text passwords over https is quite secure, the traffic is encrypted, making eavesdropping virtually impossible.

However, once on the server side, it is still plain text. Of course, storing the passwords needs proper encryption, etc. But how about monitoring tools, logging, etc.? Isn't it possible that plain text passwords end up in logs, etc? Even when using POST?

If we'd monitor the communication, we'd also see the passwords in plain text. A simple digest instead of plain text would make it harder for us to see and remember it. Yes, I can access a lot of sensitive data anyway. Yes, I can use rainbow tables to decrypt the MD5 hash. If we want to do bad, we can do bad. But why should we allow the possibility for me and colleagues to see plain text passwords?

Since people tend to use the same password for multiple online services, having someones password gives access to more that just our data of that person.

Taco Jan Osinga
  • 141
  • 1
  • 3
  • 4
    This is what authentication models such as CHAP attempt to solve. Implementing your own solution is ill-advised, though. – Polynomial Mar 05 '15 at 14:28
  • 1
    Most questions deal about security from outside. My question is more about accessibility from the inside (server side). Although I trust myself and my colleagues, why should be able to see it? – Taco Jan Osinga Mar 05 '15 at 14:41
  • The problem is, if you do not trust the server you are talking to, then it's not secure. If you do trust the server, then HTTPS is sufficient. The only reason to mistrust the server is you reuse passwords, which **you should not be doing**. So in sum, yes, HTTPS is fine. – Scott Arciszewski Mar 05 '15 at 14:43
  • POST payload is not logged in the Webserver logs. – k1DBLITZ Mar 05 '15 at 16:02
  • Similar question here (asked yesterday): https://security.stackexchange.com/questions/83113/why-do-major-sitesfacebook-google-etc-still-send-passwords-unhashed – StackzOfZtuff Mar 05 '15 at 17:35
  • @Scott, I do trust the servers and my colleagues, but why should we send plain text passwords, if we have the technology to only send salted hashes, even over https? What happens when https gets (partly) compromised someday? Shouldn't there be another line of defense? – Taco Jan Osinga Mar 05 '15 at 17:39
  • https://www.grc.com/sqrl/sqrl.htm – Scott Arciszewski Mar 05 '15 at 18:39

2 Answers2

3

Good ideas are time-bounded.

Protecting passwords by MD5'ing them was once a good idea. Then rainbow tables and MD5 collisions were discovered. So now it is a bad idea.

Sending plain-text passwords over HTTP is a very bad idea, sending plain-text passwords over HTTPS is a very good idea by comparison, but there are still better approaches you can take.

Memory - As a general guide, you must assume that the server you are sending your credentials to is secure, so don't worry too much about plaintext passwords being held in memory unless you're looking to develop ultra-secure applications.

Logs - Logs generally do not contain any HTTP POST/UPDATE data, because that data is potentially very sensitive - and sometimes to store it in unencrypted log files would be illegal - such as when a client submits credit card details for processing a payment.

Passwords should only be sent as part of the HTTP request body, never in the URL for the site, and preferably not in HTTP headers either. BASIC HTTP authentication uses a password field in the header, primitively protected with Base64 - but this is only to prevent people shoulder-surfing the password, it won't protect it from anything else.

You could look at Client Side Password Hashing, which would involve hashing the password on the client side before it is sent to the server - thus even the server would never have the real password text (and should still further salt and hash it anyway), but this is more complicated to setup and is not recommended for anyone who doesn't fully understand what they're doing.

Community
  • 1
StampyCode
  • 435
  • 4
  • 8
  • 1
    I recommend mixing Client-Side Password Hashing with additional server-side security. Personally, I use Client-Side Password Hashing on my websites with a public, constant salt. However, once that password hash reaches my server, it is then hashed again with another unique salt that is randomly generated for each user at registration. This prevents rainbow tables and it prevents my server from ever seeing the plaintext password. – Spencer D Oct 17 '15 at 17:16
  • @SpencerDoak, or you are "unhashing" (decrypting) the password somehow on the server side to hash it again or you are taking the hash sent by the user as the password itself. In each case, the actual string that gives access to the resource **is** being seen in plaintext by the server, which -- BTW -- is something extremely difficult to avoid. – Victor Schröder Jan 18 '19 at 12:36
  • @VictorSchröder I don't run the site referenced in my comment anymore, but I used the hash sent by the "user" as the password itself. Of course, that does mean that the string that gives access to the resources is seen in plaintext, but the string which was used to derive that string is NOT visible. While this does not help to protect one's own site, it protects users against Eve, in case they use the same password on multiple sites. If the actual password is sent in plaintext & Eve somehow can listen in (bad CA, server compromise, etc), then Eve may be able to use the password on other sites. – Spencer D Jan 19 '19 at 18:45
2

Sending plain text passwords over HTTPS is secure.

If you are concerned about logging you should check your entire implementation including frameworks and tools. There might be some AOP code that might get to the data before you access the variables content. So logging code might be a security issue.

Always remember to add a salt to the password before hashing it.

ST2OD
  • 227
  • 1
  • 2
  • 4
  • 2
    The advice to salt a password is like saying "Always sharpen your pocket knife before walking through bear territory." Too little, too late. You should be using a secure password storage mechanism. Even PHP got this right eventually, defaulting to bcrypt when you use `password_hash` and `password_verify`. – bonsaiviking Mar 05 '15 at 14:54