How can we encrypted user credentials when they are transmitted with php? (in login forms)
Thanks
I would have given you a +1 but there is no point in using https for the login page if you just spill the session id a few milliseconds later. Read the owasp top 10.
Rook
2010-06-21 19:55:18
@The Rook well, more or less. You can make certain actions require another you confirm your credentials. And since the users frequently recycle their passwords, they are less exposed even if someone is listening.
Artefacto
2010-06-21 20:05:57
@Artefacto yeah but your still going to get hacked due to a owap violation.
Rook
2010-06-21 20:15:20
+3
A:
The easiest way is to use a form action that's a https url, e.g.:
<form action="https://example.com/target.php" method="post">
Alternatively, you could do some kind of digest authentication. The server would send a nonce and a challenge and you, via javascript, would use that data and the password to build a digest you'd send the server for it to check. For an example, see HTTP digest authentication.
Artefacto
2010-06-21 17:54:38
Nope. HTTPS only works if the entire session is protected by it. Without covering the entire session, you can only save your password from being stolen at best, but why does the attacker care about your password when he can have your session?
Longpoke
2010-06-21 22:08:32
@Lon Because e.g. certain privileged actions may require that you provide your credentials again; because the session may be restricted to a IP; because the session has a time limit; because the password, which users regularly recycle, is not exposed, etc. Yes, the only completely safe solution is to encrypt **everything**, and not just the session, also the form in which the credentials are submitted, otherwise an active attacker could change the form action.
Artefacto
2010-06-21 22:23:26
way to take what I said literally. Encrypting the entire session usually implies all the data passed between the client and server is encrypted. And no, asking for authentication at certain points is insecure because there's no way to ensure a fake proxy session isn't setup by the attacker. Once you leave HTTPS there is no going back.
Longpoke
2010-06-21 23:07:03
@Lon You changed the needed assumptions between the two commentaries. While your first one required only a passive attacker, now you require an active one. And you ignored the other mitigating factors for session cookie sniffing. Anyway, this discussion is pointless. We know that protection against active attackers requires encryption and a PKI or a chain of trust. My argument was never that encrypting the login data was super-secure, it was that it may mitigate or even prevent most attacks.
Artefacto
2010-06-21 23:29:10
+3
A:
You can use one of the following to prevent the password being sent over the line in plain text:
- Use HTTPS.
- Use HTTP Digest authentication.
- Encrypt the password using Javascript.
Sjoerd
2010-06-21 17:56:02
Encrypt the password using Javascript is not a good option. How would you give the client the secret securely (the key with which to encrypt the password)? You'd have to use https or use a diffie-hellman key exchange.
Artefacto
2010-06-21 18:02:24
It is possible to do SHA1 in Javascript. This way, the password hash can not be decrypted but it can be checked against the database. There are also people who try to do Diffie-Hellman in Javascript.
Sjoerd
2010-06-21 18:18:04
Unlike Digest and SSL, a Javascript encryption does not protect against man-in-the-middle attacks. But it DOES encrypt the traffic, thus prevents sniffing. Incomplete, but worlds better than a plain form.
mario
2010-06-21 18:40:54
Digest access authentication is also vulnerable to Man-in-the-middle attack, if used over HTTP. For example, a MitM attacker could tell clients to use Basic access authentication.
Sjoerd
2010-06-21 19:14:57
@Sjoerd Your reasoning is wrong. If you hash the password and send it to the server to authenticate yourself, you might as well call the hash a password.
Artefacto
2010-06-21 19:58:40
@mario If you go down that road, http + https login page is also vulnerable. An attacker could intercept the http request and change the form action from "https://..." to "http://...". Nothing is entirely safe except encrypting everything.
Artefacto
2010-06-21 20:07:28
@Artefacto The website would supply a nonce which is different every time, and is hashed together with the password. This guards against a replay attack.
Sjoerd
2010-06-21 20:25:01
@Sjoerd Then you're implementing a simple version of digest authentication, which is not what "encrypt the password using Javascript" conveys. "message digest" != "cyphertext", "encrypt" generally denotes building cyphertext from plain text, not applying a hash algorithm.
Artefacto
2010-06-21 20:31:14
+2
A:
"user credentials" are not just the username and password. A user credential is any data that is used for authentication. There is no point in using https for the login page if you just spill the session id a few milliseconds later by using http. The session id, is a credential and must be protected just like a username/password.
You must use https for the entire session. Spilling the session id over HTTP is a clear violation of The OWASP top 10: Broken Authentication and Session Management.
Rook
2010-06-21 19:57:50
@The Rook, Could you please take a look at this link?http://stackoverflow.com/questions/3087483/a-book-or-tutorial-about-secure-user-management-and-privilegesThank you very much.
phpExe
2010-06-21 22:01:51