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.

Improve this question
7
  • 4
    This is what authentication models such as CHAP attempt to solve. Implementing your own solution is ill-advised, though.
    – Polynomial
    Mar 5, 2015 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 5, 2015 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 5, 2015 at 14:43
  • POST payload is not logged in the Webserver logs.
    – k1DBLITZ
    Mar 5, 2015 at 16:02
  • Similar question here (asked yesterday): security.stackexchange.com/questions/83113/…
    – StackzOfZtuff
    Mar 5, 2015 at 17:35

2 Answers 2

Reset to default
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.

Improve this answer
3
  • 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, 2015 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, 2019 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, 2019 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.

Improve this answer
1
  • 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 5, 2015 at 14:54

Not the answer you're looking for? Browse other questions tagged .