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?
views:
574answers:
4
+8
A:
If HTTP is disabled, and you only use HTTPS, then you're not really transmitting the password as plain text anyway.
Can Berk Güder
2009-06-07 16:11:07
+8
A:
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.
Eduardo Scoz
2009-06-07 16:11:12
Minor nitpick: some login forms use JavaScript to hash the password instead of sending it plain text.
Thorarin
2009-06-07 18:35:01
@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
2010-02-14 20:59:46
@DGM: double hashing is also an option, so plain text passwords are not strictly necessary.
Thorarin
2010-02-16 13:43:24
+5
A:
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.
Andrew Medico
2009-06-07 16:31:34
+1
A:
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...
grossvogel
2009-06-07 16:36:30
Yes, I realize this, thanks, I was merely referring to the transmission here.
Hugo
2009-06-07 16:43:41