I'm currently working on a PHP OpenID provider that will work over HTTPS (hence SSL encrypted).
Is it wrong for me to transmit the password as plain text? HTTPS in theory, cannot be intercepted, so I don't see anything wrong. Or is this unsafe at some level and I'm failing to see this?

- 9,423
- 6
- 62
- 70
7 Answers
It is safe. That's how the entire web works. All passwords in forms are always sent in plain text, so its up to HTTPS to secure it.

- 24,653
- 6
- 47
- 62
-
26Minor nitpick: some login forms use JavaScript to hash the password instead of sending it plain text. – Thorarin Jun 07 '09 at 18:35
-
5@Thorarin if they truly hash it, that means the server is storing the password in plain text so it can hash with the same salt to verify. Ick! Sending the password in ssl wrapped text is better, as the server does not then need to store the password in plain text. – DGM Feb 14 '10 at 20:59
-
13@DGM: double hashing is also an option, so plain text passwords are not strictly necessary. – Thorarin Feb 16 '10 at 13:43
-
Yahoo used client side password hashing before switching to https implementation – Denis Jul 06 '11 at 07:46
-
3@Denis: client side hashing doesn't really help much. It may make things a bit harder than plain text, but somebody who really wants to steal a password can do it with no problems. Only would safely work if you send at least a one-time token over a secure channel (ssl), in which case you might as well just send the password in SSL to start with. – Eduardo Scoz Jul 06 '11 at 13:57
-
5I am just saying that Yahoo felt that client side hashing was secure enough until they could afford to move all the way to ssl. But hey, I am all for https :) – Denis Jul 06 '11 at 18:16
-
@EduardoScoz Yes, you're right. If they can intercept the hash, they can still login as you (by simply sending the server the hash). It does practically _nothing_ except stop the hacker from learning the actual characters in your password. – bobobobo Apr 22 '13 at 21:46
-
1JS hashing add no value, even if the server double-hashes the passwords. In that scenario, obtaining the submited has allows the interceptor to log in as the victim; much like they would if the password had been plain text. – WhyNotHugo Aug 23 '13 at 22:42
-
2@Hugo there is value in that if the victim uses the password for multiple accounts, this will at least safeguard the password being leaked – WaelJ Jul 15 '15 at 10:21
-
@WaelJ True, though this only applies if the server keys are compromised, or if the server is compromised during the exchange. Also note that double hashing has some caveats, and should be done with caution. – WhyNotHugo Jul 15 '15 at 18:58
-
1@EduardoScoz "It's safe because it has to be safe". That in itself is a very dangerous line of reasoning. – remcoder Jun 20 '16 at 19:50
-
@Thorarin it wont be the case for checking password is correct or incorrect.. like if you want password to be matched from user form with the password in server database. – khunshan Sep 07 '17 at 19:47
-
1@EduardoScoz - but still I can see the plan text passwords in browser network panel even if its https ? – King_Fisher Apr 23 '19 at 13:01
-
1@King_Fisher the communication between your browser and the website is secured, that's guaranteed by SSL. – Eduardo Scoz Apr 23 '19 at 19:30
-
But also I can able to view the API request from the fiddler. How this can be secured then? – King_Fisher Apr 23 '19 at 19:32
-
1Your server can see your plain password isn't it violating a lot of things. – Sandeep Rana Jan 13 '20 at 13:01
-
1@SandeepSinghRana no, the server is already a trusted part of the entire process, it served the html page and javascript that executes on the client. There's no point in trying to make that secure, because if somebody gets access to the server it could always change the page to get the password from the user anyway. – Eduardo Scoz Jan 14 '20 at 02:00
-
@DGM I always thought a good way would be for servers to store a hash instead of plain text passwords. When a request with a hashed password arrives server must only compare the received hash with the stored hash from DB. Is that good or am I wrong? Also the answer sounds good and all, but do we have any references where we can read more about it? – Bitterblue Jun 09 '21 at 17:41
-
@Bitterblue Indeed, servers should ONLY store hashes, along with a SALT that is not shared outside of the server. Thus, the client must send the actual password via SSL, encrypted in transit, where the server looks up the salt characters and uses that and the supplied password to hash, and compares that to the stored value. using salt in this way prevents dictionary attacks with rainbow tables. – DGM Jun 10 '21 at 18:40
You still need to make sure you send it via POST request, not GET. If you send it via GET request, it could be saved in plaintext in the user's browser history logs or the webserver's access logs.

- 19,814
- 17
- 56
- 77
-
8Yes, I knew that, but it's still a good comment to leave behind for others that come looking here. :) – WhyNotHugo Jun 21 '14 at 08:24
-
If HTTP is disabled, and you only use HTTPS, then you're not really transmitting the password as plain text anyway.

- 109,922
- 25
- 130
- 137
-
4However the server _does_ have access to your plaintext password, they can store it as plaintext, log it incorrectly as plaintext etc. That is to say, your password doesn't stay on the client side, the server also sees exactly what it is. – xref Mar 21 '19 at 20:02
Hash client side. Why? Let me tell you about a little experiment. Walk up to computer in company cafeteria. Open browser to company web site login page (https). Press F12, click network tab, check off persist log, minimize console but leave web page open to login page. Sit down and eat lunch. Watch as employee after employee logs on to the company web site and being a good little worker logs out when done. Finish lunch, sit down at computer bring up network tab and see every single username and password in plain text in the form bodys.
No special tools, no special knowledge, no fancy hacking hardware, no keyloggers just good old F12.
But hey, keep thinking all you need is SSL. The bad guys will love you for it.

- 265
- 2
- 3
-
13Your cafeteria comment doesn't make any sense, no matter how much I re-read it. Why would people just walk up to a computer and type their credentials? What are you trying to prove? Also, hashing won't make this *more* insecure, in any way. It was a common thing to hash passwords and transmit them over plain-text HTTP when this question was written, in 2009. – WhyNotHugo Jul 26 '17 at 00:32
-
8I upvoted both of these because, yes, the accepted answer _is_ being read many years later. It would be good if @CodeDog would please point to some mitigation strategy. And yes, people will just walk up to random PCs, for example, in the local library, and enter their details! – JoeAC Jul 26 '17 at 05:17
-
4I encrypt passwords client side with a public key, then post only the encrypted password in the form. It is an asymmetrical key so having the client side public key is useless for the attackers. Every log it generates a new key pair so replay attacks wont work either. The key even changes on failed log in attempts. The key pairs are generated server side when the users arrives at the log in screen. Only the public key is provided to the client side code. – CodeDog Jul 29 '17 at 06:11
-
BTW I have seen this hack being used at a hotel business center by staff in order to gather passcodes for room numbers. They would use the passcode to get on the wireless and to use the business center pcs and it would be billed to the room. – CodeDog Jul 29 '17 at 06:17
-
1I performed such an experiment myself loging into my bank account and must agree with @CodeDog - Request payload include my login and password both plaintext. – Artur Michajluk Jan 15 '18 at 15:10
-
-
-
That's a matter of physical security, not a matter of encryption. Even if I were to do this with hashed passwords, whats stopping me from using that hash to get information from the login server? In the end it's the same. – Rawley Fowler Oct 20 '21 at 18:13
-
1@Ivan There is the possibility of the server providing a salt/key which the client has to use to hash the password. If that changes on every request, then even reading the hash will be useless for replay attacks. It is explained by CodeDog. – Lucas Manzke Oct 21 '21 at 12:12
Let’s make some notes to previous answers.
First, it’s probably not the best idea to use hash algorithms client side because if your password is salted on the server side, you won’t be able to compare hashes (at least not if you don’t store the client hash in the database in one of the hashing layers from the password, which is the same or worse). And you don’t want to implement the hashing algorithm used by the database on the client side, it would be silly.
Second, trading off cryptographic keys aren’t ideal either. The MITM could theoretically (considering he has a root cert installed on the client) change the cryptographic keys, and change with his own keys:
Example from an original connection (not considering TLS) from a theoretical server that exchanges keys:
Client request public keys > server holds the private keys, generate public keys to client > server sends public keys to client
Now, in a theoretical MITM atrack:
Client request public keys > MITM generates fake private keys > Server holds the private keys, generate public keys to client > MITM receives the public keys from the original server, now, we’re free to send our fake public keys to the client, and whenever a request comes from the client, we will decrypt the client data with the fake keys, change the payload (or read it) and encrypt with the original public keys > MITM sends fake public keys to client.
That’s the point of having trusted CA certificate in TLS, and that’s how you receive a message from the browser warning if the certificate isn’t valid.
In response to the OP: in my humble opinion you can’t do that, because sooner or later, someone will want to attack a user from your service and will try to break your protocol.
What you can do, however, is to implement 2FA to prevent people from ever trying to login with the same password. Beaware of replay attacks, though.
I’m not great with cryptography, please correct me if I’m wrong.

- 1,308
- 12
- 23
-
1Keep in mind that this discussion is from 2009. These were pretty much the best practices at the time. – WhyNotHugo Aug 26 '18 at 18:59
-
4@WhyNotHugo I’m aware. I decided to leave an answer because the top google answer to this question led me here, so why not. – Lucca Ferri Aug 26 '18 at 19:30
@CodeDog example has issues..
Yes, I can believe that users will log into a caffeteria box. If you are capturing logs from a corporate caffeteria, then you are the security breach. Corporate caffeterias boxes should be setup disabled, e.g. no terms, no loggers, no remote access, etc. In order to prevent you, the inside hacker.
The example is a good one of computer access security, and not really related to network security. It is provided as justification for client side hashing, but if you have computer access you could just use a keystroke logger and bypass that. The client side hash is again irrelevant. The example by @CodeDog is a computer access hack and requires techniques different from network layer hacks.
Also, a public computer hack is protected by crippling the system from threats, as mentioned above. e.g. use a chromebook for a public caffeteria computer. But that is bypassed by a physical hack. During off hours, go to the caffeteria and setup a secret camera to record keyboard presses by users. Then it doesnt matter if the caffeteria computer is crippled, OR what type of encryption is used.
physical layer -> computer layer -> client layer -> network layer -> server layer
For networking, doesnt matter if you hash on client side because the https/ssl layer will encrypt the plain passwd. So as others mention the client hashing is redundant if the TLS is secure.
-
3While you make good points, you are replying to an answer (which itself is not really relevant to the question asked) so isn't really appropriate for the Stackoverflow Q&A model. – Martin Aug 24 '20 at 20:40
The other posters are correct. Now that you're using SSL to encrypt the transmission of the password, make sure you're hashing it with a good algorithm and salt so it's protected when it's at rest, too...

- 6,694
- 1
- 25
- 36
-
Yes, I realize this, thanks, I was merely referring to the transmission here. – WhyNotHugo Jun 07 '09 at 16:43