I noticed that most sites send the passwords as plain text over HTTPS to the server. Is there any advantage if instead of that I sent the hash of the password to the server? Would it be more secure?
+4
A:
No, in fact this would be a vulnerability. If the attacker is able to obtain the hash from the database, then he could use it to authenticate without needing to crack it. Under no circumstance should a user or an attacker be able to obtain a hashes password.
The whole point of hashing passwords is to add an extra layer of secuirty. If an attacker is able to obtain the hash and salt from the database using SQL Injection or an insecure backup then he has to find the plain text by brute forcing it. John The Ripper is commonly used to break salted password hashes.
Not using https is a violation of the OWASP Top 10: A9-Insufficient Transport Layer Protection
EDIT:
If in your implantation you calculate a sha256(client_salt+plain_text_password) and then calculate another hash on the server side sha256(server_salt+client_hash) then this is not a serious vulnerability however it is still susceptible to ease dropping and replaying the request. Thus this is still a clear violation of WASP A9. However, this is still utilizing a message digest as a security layer.
The closest thing i have seen to a client-side replacement for https is a diffie-hellman in key exchange in javascript. However, this does prevent active MITM attacks and thus is till technicality a violation of OWASP A9. The Authors of the code agree that this is not a complete replacement for HTTPS, however it is better than nothing and better than a client-side hashing system.
Rook
2010-08-02 19:56:09
Actually I would hash it again in the server, so please edit your answer contemplating this scenario.
Jader Dias
2010-08-02 20:00:12
@Jader Dias updated.
Rook
2010-08-02 20:24:20
+4
A:
Since it's over HTTPS, it's definitely just fine to send the password without hashing (over HTTPS it's not plaintext). Furthermore, if your application is depending on HTTPS to keep it's content secure, then it's useless to hash the password before sending it over HTTPS (i.e. if an attacker can unencrypt the data on the wire, you're screwed anyways)
carnold
2010-08-02 19:56:55
I fear that HTTPS data is intercepted by proxies, and hashing it in the client would prevent they becoming leak points. Do you agree?
Jader Dias
2010-08-02 20:01:51
This shouldn't be a problem. If the client is using a proxy, then all the proxy will see is the HTTPS encrypted data. If you're talking about a man-in-the-middle attack, a properly configured certificate should prevent this.
carnold
2010-08-02 20:03:50
@Jader: No amount of fiddling with the data will stop a MITM attack, since it can just relay whatever comes to it. It doesn't matter whether you're transmitting a password or hash. That's a completely different matter.
David Thornley
2010-08-02 20:10:52
@David I think a challenge-based encryption could prevent a replaying the hash, so it would be useless to intercept a password hashed with a one-time salt (the challenge).
Jader Dias
2010-08-02 20:15:42
@David s/challenge/nonce/g http://en.wikipedia.org/wiki/Cryptographic_nonce
Jader Dias
2010-08-02 20:20:05
@carnold - MINTM - What about redirecting to http? Would most people notice? sslstrip - http://www.securityfocus.com/brief/910
nate c
2010-08-02 20:38:28
@Jader: So, what in nonce would prevent a MITM attack? The only thing it would do is prevent a replay attack, and the MITM already has full access for the duration of the session. Is it worth complicating things to hinder turning full access into permanent full access?
David Thornley
2010-08-02 20:48:33
@Jader Dias your trying to stop a problem that doesn't exist. HTTPS stops this problem, a client side hash does not add any amount of security. The client can never be trusted.
Rook
2010-08-02 22:40:13
@David Thornley - You said that "No amount of fiddling with the data will stop a MITM attack, since it can just relay whatever comes to it," but Jader pointed out that a nonce defeats replay attacks. Can you explain how to MITM a TLS connection without generating a client warning?
bowenl2
2010-08-03 17:14:16
@bowenl2: A nonce defeats replay attacks, in the sense that it's impossible for an eavesdropper to replay the credential later and get into a session. A MITM would accept the challenge from one side, replay it to the other, and then do the same in the reverse direction with the response, so a nonce-based solution won't do squat against MITM. The only way to defeat MITM is to authenticate who you're immediately talking to, which means certificates that are independently authenticated and which you can rely on, which isn't quite the case today (cont)
David Thornley
2010-08-03 17:24:05
(from cont) because (a) not all certificate authorities are completely trustworthy and immune to deception, and (b) not all certificate holders use their certificates properly (so that dealing with them requires violating good security practice).
David Thornley
2010-08-03 17:25:52
A:
It would actually be less secure to hash the password and send it over a non-encrypted channel. You will expose your hashing algorithm on the client. Hackers could just sniff the hash of the password and then use it to hack in later.
By using HTTPS, you prevent a hacker from obtaining the password from a single source, since HTTPS uses two channels, both encrypted.
Carter
2010-08-02 19:57:36
Actually I would hash it again in the server, and I would use HTTPS anyway, so please edit your answer contemplating this scenario.
Jader Dias
2010-08-02 20:02:48
@Jader, the point is, all an attacker needs now is the first hash, rather than a password. In effect, the hash you take of the password on the client side is now just as useful as the password itself. So you're not really gaining much security.
Peter Recore
2010-08-02 20:39:59
A:
If you're connected to an https server the data stream between the server and browser should be encrypted. The data is only plain text before being sent and after being recieved. Wikipedia article
Beaner
2010-08-02 20:00:48
As I understand it they do, but the proxy is not responsible for encryption/decryption and unless it is an unscrupulous proxy only passes the data on. The encryption type and strength is dependent on what the server and client can both support.
Beaner
2010-08-02 20:17:02
@Beaner - Even if the proxy is unxrupulous, it can't decrypt the data as it is encrypted using the server's public key. The only way a proxy can decrypt the data is to spoof the server's certificate with a different key
carnold
2010-08-02 20:32:06
@Jader. If they did, it would make HTTPS pretty lame. when you authenticate to a server with HTTPS, you are getting a guarantee (assuming the certificate is valid) that you are connecting to a certain server, and have an encrypted path from one end to the other. Hypothetically, a man in the middle attack could be done to fool you of course, but that is not the same as a basic web proxy.
Peter Recore
2010-08-02 20:44:03
+1
A:
Use HTTP Digest - it secures the password even over http (but best useage would be http digest over https)
Wikipedia:
HTTP digest access authentication is one of the agreed methods a web server can use to negotiate credentials with a web user (using the HTTP protocol). Digest authentication is intended to supersede unencrypted use of the Basic access authentication, allowing user identity to be established securely without having to send a password in plaintext over the network. Digest authentication is basically an application of MD5 cryptographic hashing with usage of nonce values to prevent cryptanalysis.
Link: http://en.wikipedia.org/wiki/Digest_access_authentication
If you want to see a "real life" use, you could look at phpMyID - a php openid provider that uses http digest authentication http://siege.org/phpmyid.php
.. or you could start from the php auth samples at http://php.net/manual/en/features.http-auth.php
Http digest rfc: http://www.faqs.org/rfcs/rfc2617
From my tests all modern browsers support it...
vlad b.
2010-08-02 20:05:29
HTTP Digest implements what I meant in this question, but would we have any advantage if we used HTTPS Digest (SSL + HTTP Digest) ?
Jader Dias
2010-08-02 20:21:35
One main difference would be that everything is sent/received encrypted - http headers send and received and the html reply. To someone randomly trying to "hack" ssl using a man-in-the-middle-attack the http digest would be an extra motive to make him search another easier target, or if he is logging all captured traffic your passwords is still safer.I may have misunderstood the question, english is not my first language.
vlad b.
2010-08-02 20:54:32
Hash over password has one big advantage: if the traffic is logged or captured somehow it will make the job harder for that person.Also, with http digest, if ssl is not always required, you could let users choose between http and https. Or you could use different protocols for diferent servers (for example i do not enforce https to view/modify less importand data (username, avatar uploading) but enforce https on billing and other parts of the site (that way i can decrease the load on some servers, if/when needed).
vlad b.
2010-08-02 20:58:06
+1
A:
Sending a hash over the wire completely defeats the purpose of the hash, because an attacker can simply send the hash and forget about the password. In a nutshell, a system that athenticates using a hash in clear text is wide open and can be compromise with nothing more than network sniffing.
Paul Keister
2010-08-02 20:07:56
A:
If you're looking to replace a clear-text password over HTTPS with a hashed password over HTTP then you're asking for trouble. HTTPS generates a random, shared transaction key when opening up a communication channel. That's hard to crack, as you're pretty much limited to brute forcing the shared key used for a (relatively) short-term transaction. Whereas your hash can be just sniffed, taken off-line and looked up in a rainbow table or just brute forced over a long amount of time.
However, a basic client-side password obfuscation (not hash) sent over HTTPS does have some value. If I'm not mistaken this technique is actually used by some banks. The purpose of this technique is not to protect the password from sniffing over the wire. Rather, it's to stop the password from being usable to dumb spying tools and browser plug-ins that just grab every HTTPS GET/POST request that they see. I've seen a log file captured from a malicious website that was 400MB of random GET/POST transactions captured from user sessions. You can imagine that websites that used just HTTPS would show up with clear-text passwords in the log, but websites with very basic obfuscation (ROT13) as well would show up with passwords that are not immediately of use.
Simon Ellis
2010-08-04 05:31:26