Re: [drupal-devel] Securing Login: MD5 password hashing using javascript
On Tue, 8 Nov 2005 18:14:58 +0100, =?ISO-8859-1?Q?Konstantin_K=E4fer?= <kkaefer@gmail.com> wrote :
Hello,
Why should sending the password hashed increase security? Just get the hashed password and provide that to the script (of course not by entering it in the password field but by "faking" the HTTP POST values).
The only way to protect the password is using SSL or TLS.
True, but not everybody can use ssl/tls. What about some kind of authentication checking where the site would keep track of where you have logged in from and upon detection of a change would prompt you with a question that only you would know or send you an email that you would have to respond to before you could gain access? Pat
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08 Nov 2005, at 7:29 PM, Pat Collins wrote:
On Tue, 8 Nov 2005 18:14:58 +0100, =?ISO-8859-1?Q?Konstantin_K=E4fer?= <kkaefer@gmail.com> wrote :
Hello,
Why should sending the password hashed increase security? Just get the hashed password and provide that to the script (of course not by entering it in the password field but by "faking" the HTTP POST values).
The only way to protect the password is using SSL or TLS.
True, but not everybody can use ssl/tls. What about some kind of authentication checking where the site would keep track of where you have logged in from and upon detection of a change would prompt you with a question that only you would know or send you an email that you would have to respond to before you could gain access?
Like certain ISP's that change the ip of the user with ever request ? 'where you have logged in from' is mostly impossible to determine. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDcORSgegMqdGlkasRAmULAKCnx9c10DpansVaIdIOZ5vu62OPUACeKInz mvK7AEjymAqABbxGDVMMRyM= =I4Rd -----END PGP SIGNATURE-----
On Tue, Nov 08, 2005 at 12:29:56PM -0500, Pat Collins wrote:
True, but not everybody can use ssl/tls. What about some kind of authentication checking where the site would keep track of where you have logged in from and upon detection of a change would prompt you with a question that only you would know or send you an email that you would have to respond to before you could gain access? If a user is really so concerned about security, he/she should just get SSL. Saying "if someone has no access to SSL/TLS, but still wants security" sounds like saying "I want my house burglar-safe, but do not want to pay for good safe locks".
I dislike the idea of using Javascript for hashing. It smells a lot like security through obscurity. And it brings a lot of new problems. I think we should simply re-use the existing tools. SSL and TLS. Ber
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password. I also agree with you that SSL is the ultimate solution if one really needs security. However, I think that SSL in Drupal is an All Or None approach. Either the entire site is SSL, or not SSL. There is no way at present where only the login is https, and the rest is http. If this is addressed, then the whole argument for these half baked solutions goes away: need security? Get SSL for login. Period. On 11/9/05, Bèr Kessels <ber@webschuur.com> wrote:
On Tue, Nov 08, 2005 at 12:29:56PM -0500, Pat Collins wrote:
True, but not everybody can use ssl/tls. What about some kind of authentication checking where the site would keep track of where you have logged in from and upon detection of a change would prompt you with a question that only you would know or send you an email that you would have to respond to before you could gain access? If a user is really so concerned about security, he/she should just get SSL. Saying "if someone has no access to SSL/TLS, but still wants security" sounds like saying "I want my house burglar-safe, but do not want to pay for good safe locks".
I dislike the idea of using Javascript for hashing. It smells a lot like security through obscurity. And it brings a lot of new problems. I think we should simply re-use the existing tools. SSL and TLS.
Ber
I agree that there's no substitute for SSL, and I also agree that some security is better than no security. As the author originally stated, this doesn't necessarily protect the current session (you can hijack a session by sniffing cookies anyway), but it protects against collecting passwords for other uses. Why can't this be done in contrib? On Nov 9, 2005, at 9:29 AM, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
I also agree with you that SSL is the ultimate solution if one really needs security.
Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
On Wednesday 09 November 2005 10:29, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
Not necessarily. Assume a password of "secret", have the browser do this: 1. Generate a random text string, let's say "x!Q37_z*P" for example, in the JavaScript in the browser. 2. The browser takes the MD5 sum of the password: "5ebe2294ecd0e0f08eab7690d2a6ee69". 3. The browser then concatenates the password MD5 and the random string, with a carriage return between: "5ebe2294ecd0e0f08eab7690d2a6ee69" . "\n" . "x!Q37_z*P". 4. The browser takes the MD5 sum of that entire string: "ec1e557633decf2c14c306af381c9011" 5. Now the browser sends to the server the cleartext version of the random string, concatenated with a carriage return and the combined MD5: "x!Q37_z*P" . "\n" . "ec1e557633decf2c14c306af381c9011" 6. At the server end, we have the MD5 of the real password in the database. Retrieve that. Concatenate it with the one-time pad (the random string, easily extracted from what the browser sent) and CR. Then, take the MD5 sum of the whole thing. It should match what the browser sent after the CR. This nonce or one-time-pad technique is very common in authentication schemes. It won't stop a playback or man-in-the-middle attack, but it *does* keep the actual MD5 of the password from being exposed. The only cleartext sent is the nonce, and the only MD5 sent is one that included the nonce in its creation. The technique can be further refined by having the *server* supply the nonce string as a "HIDDEN" parameter in the login form itself, ignored by a non-JS client but used by the JS encryptor. The server then can keep track of the nonce values it has recently used, and only accept those values in submitted forms. Each time one of those nonces is used, delete it from the table in the server's memory, so that each nonce can only be used once by a POST operation. This effectively stops the playback attack, because the attacker would have to get back to the server *before* the client does, else that nonce will be already invalidated. And the attacker can't play back what it hasn't seen yet. I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
On 11/9/05, Syscrusher <scott@4th.com> wrote:
I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet.
On a somewhat related topic, I have always been hesitant about the drupal.module feature of logging into a site using an account from another system because it would be possible for a malicious admin to modify drupal.module on his site to capture the password. It might be possible to use the above method, in combination with something else, to protect against sending a plain text password through the site being visited. Of course I'd love to be wrong about the whole thing.
My comments was on the original scheme. I have to admit that yours is far better, but since I am no security guru, I will leave poking holes in it to those who are more adept than me in this. One drawback I see is this cannot be the only authentication way, since someone may turn off javascript in their browser. If we allow graceful degradation, then we are back to either SSL or the existing scheme with all its deficiencies. On 11/9/05, Syscrusher <scott@4th.com> wrote:
On Wednesday 09 November 2005 10:29, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
Not necessarily. Assume a password of "secret", have the browser do this:
1. Generate a random text string, let's say "x!Q37_z*P" for example, in the JavaScript in the browser.
2. The browser takes the MD5 sum of the password: "5ebe2294ecd0e0f08eab7690d2a6ee69".
3. The browser then concatenates the password MD5 and the random string, with a carriage return between: "5ebe2294ecd0e0f08eab7690d2a6ee69" . "\n" . "x!Q37_z*P".
4. The browser takes the MD5 sum of that entire string: "ec1e557633decf2c14c306af381c9011"
5. Now the browser sends to the server the cleartext version of the random string, concatenated with a carriage return and the combined MD5: "x!Q37_z*P" . "\n" . "ec1e557633decf2c14c306af381c9011"
6. At the server end, we have the MD5 of the real password in the database. Retrieve that. Concatenate it with the one-time pad (the random string, easily extracted from what the browser sent) and CR. Then, take the MD5 sum of the whole thing. It should match what the browser sent after the CR.
This nonce or one-time-pad technique is very common in authentication schemes. It won't stop a playback or man-in-the-middle attack, but it *does* keep the actual MD5 of the password from being exposed. The only cleartext sent is the nonce, and the only MD5 sent is one that included the nonce in its creation.
The technique can be further refined by having the *server* supply the nonce string as a "HIDDEN" parameter in the login form itself, ignored by a non-JS client but used by the JS encryptor. The server then can keep track of the nonce values it has recently used, and only accept those values in submitted forms. Each time one of those nonces is used, delete it from the table in the server's memory, so that each nonce can only be used once by a POST operation. This effectively stops the playback attack, because the attacker would have to get back to the server *before* the client does, else that nonce will be already invalidated. And the attacker can't play back what it hasn't seen yet.
I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet.
Scott
-- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
On Wednesday 09 November 2005 11:30, Khalid B wrote:
I have to admit that yours is far better, but since I am no security guru
Neither am I. :-) I make no claims that my scheme is "secure", only that it is "less insecure" than sending the actual password MD5 across the wire. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
On Wed, 2005-11-09 at 10:53 -0500, Syscrusher wrote:
On Wednesday 09 November 2005 10:29, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
Not necessarily. Assume a password of "secret", have the browser do this:
1. Generate a random text string, let's say "x!Q37_z*P" for example, in the JavaScript in the browser.
2. The browser takes the MD5 sum of the password: "5ebe2294ecd0e0f08eab7690d2a6ee69".
3. The browser then concatenates the password MD5 and the random string, with a carriage return between: "5ebe2294ecd0e0f08eab7690d2a6ee69" . "\n" . "x!Q37_z*P".
4. The browser takes the MD5 sum of that entire string: "ec1e557633decf2c14c306af381c9011"
5. Now the browser sends to the server the cleartext version of the random string, concatenated with a carriage return and the combined MD5: "x!Q37_z*P" . "\n" . "ec1e557633decf2c14c306af381c9011"
6. At the server end, we have the MD5 of the real password in the database. Retrieve that. Concatenate it with the one-time pad (the random string, easily extracted from what the browser sent) and CR. Then, take the MD5 sum of the whole thing. It should match what the browser sent after the CR.
This nonce or one-time-pad technique is very common in authentication schemes. It won't stop a playback or man-in-the-middle attack, but it *does* keep the actual MD5 of the password from being exposed. The only cleartext sent is the nonce, and the only MD5 sent is one that included the nonce in its creation.
The technique can be further refined by having the *server* supply the nonce string as a "HIDDEN" parameter in the login form itself, ignored by a non-JS client but used by the JS encryptor. The server then can keep track of the nonce values it has recently used, and only accept those values in submitted forms. Each time one of those nonces is used, delete it from the table in the server's memory, so that each nonce can only be used once by a POST operation. This effectively stops the playback attack, because the attacker would have to get back to the server *before* the client does, else that nonce will be already invalidated. And the attacker can't play back what it hasn't seen yet.
I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet.
Scott
Sounds like a JS/html chap implementation...
On Wednesday 09 November 2005 12:45, Darrel O'Pry wrote:
Sounds like a JS/html chap implementation...
Something like that. As I said in my original post, this is not my own idea, and has been used plenty of other places. :-) Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Hi, Not to put a spanner in the works, but I do not like the idea of being able to send an MD5 to the database. If they have compromised the database and have the original MD5, then they have a method of logging in without the password. But then again, if they have the MD5, they can use some md5 crackers to get the original password. Gordon. On Wed, 2005-11-09 at 10:53 -0500, Syscrusher wrote:
On Wednesday 09 November 2005 10:29, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
Not necessarily. Assume a password of "secret", have the browser do this:
1. Generate a random text string, let's say "x!Q37_z*P" for example, in the JavaScript in the browser.
2. The browser takes the MD5 sum of the password: "5ebe2294ecd0e0f08eab7690d2a6ee69".
3. The browser then concatenates the password MD5 and the random string, with a carriage return between: "5ebe2294ecd0e0f08eab7690d2a6ee69" . "\n" . "x!Q37_z*P".
4. The browser takes the MD5 sum of that entire string: "ec1e557633decf2c14c306af381c9011"
5. Now the browser sends to the server the cleartext version of the random string, concatenated with a carriage return and the combined MD5: "x!Q37_z*P" . "\n" . "ec1e557633decf2c14c306af381c9011"
6. At the server end, we have the MD5 of the real password in the database. Retrieve that. Concatenate it with the one-time pad (the random string, easily extracted from what the browser sent) and CR. Then, take the MD5 sum of the whole thing. It should match what the browser sent after the CR.
This nonce or one-time-pad technique is very common in authentication schemes. It won't stop a playback or man-in-the-middle attack, but it *does* keep the actual MD5 of the password from being exposed. The only cleartext sent is the nonce, and the only MD5 sent is one that included the nonce in its creation.
The technique can be further refined by having the *server* supply the nonce string as a "HIDDEN" parameter in the login form itself, ignored by a non-JS client but used by the JS encryptor. The server then can keep track of the nonce values it has recently used, and only accept those values in submitted forms. Each time one of those nonces is used, delete it from the table in the server's memory, so that each nonce can only be used once by a POST operation. This effectively stops the playback attack, because the attacker would have to get back to the server *before* the client does, else that nonce will be already invalidated. And the attacker can't play back what it hasn't seen yet.
I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet.
Scott
In the challenge-response they don't get in with md5($password), but rather with something like md5($challenge.$password), no? On 11/9/05, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
Not to put a spanner in the works, but I do not like the idea of being able to send an MD5 to the database. If they have compromised the database and have the original MD5, then they have a method of logging in without the password.
But then again, if they have the MD5, they can use some md5 crackers to get the original password.
Gordon.
On Wed, 2005-11-09 at 10:53 -0500, Syscrusher wrote:
On Wednesday 09 November 2005 10:29, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
Not necessarily. Assume a password of "secret", have the browser do this:
1. Generate a random text string, let's say "x!Q37_z*P" for example, in the JavaScript in the browser.
2. The browser takes the MD5 sum of the password: "5ebe2294ecd0e0f08eab7690d2a6ee69".
3. The browser then concatenates the password MD5 and the random string, with a carriage return between: "5ebe2294ecd0e0f08eab7690d2a6ee69" . "\n" . "x!Q37_z*P".
4. The browser takes the MD5 sum of that entire string: "ec1e557633decf2c14c306af381c9011"
5. Now the browser sends to the server the cleartext version of the random string, concatenated with a carriage return and the combined MD5: "x!Q37_z*P" . "\n" . "ec1e557633decf2c14c306af381c9011"
6. At the server end, we have the MD5 of the real password in the database. Retrieve that. Concatenate it with the one-time pad (the random string, easily extracted from what the browser sent) and CR. Then, take the MD5 sum of the whole thing. It should match what the browser sent after the CR.
This nonce or one-time-pad technique is very common in authentication schemes. It won't stop a playback or man-in-the-middle attack, but it *does* keep the actual MD5 of the password from being exposed. The only cleartext sent is the nonce, and the only MD5 sent is one that included the nonce in its creation.
The technique can be further refined by having the *server* supply the nonce string as a "HIDDEN" parameter in the login form itself, ignored by a non-JS client but used by the JS encryptor. The server then can keep track of the nonce values it has recently used, and only accept those values in submitted forms. Each time one of those nonces is used, delete it from the table in the server's memory, so that each nonce can only be used once by a POST operation. This effectively stops the playback attack, because the attacker would have to get back to the server *before* the client does, else that nonce will be already invalidated. And the attacker can't play back what it hasn't seen yet.
I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet.
Scott
-- Best regards, Herman Webley
Hi, On Wed, 2005-11-09 at 16:46 -0800, Herman Webley wrote:
In the challenge-response they don't get in with md5($password), but rather with something like md5($challenge.$password), no?
Yes, but if the user has the md5 from the server, then he can build the $challenge.$password to submit to the server. Gordon.
On 11/9/05, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
Not to put a spanner in the works, but I do not like the idea of being able to send an MD5 to the database. If they have compromised the database and have the original MD5, then they have a method of logging in without the password.
But then again, if they have the MD5, they can use some md5 crackers to get the original password.
Gordon.
On Wed, 2005-11-09 at 10:53 -0500, Syscrusher wrote:
On Wednesday 09 November 2005 10:29, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
Not necessarily. Assume a password of "secret", have the browser do this:
1. Generate a random text string, let's say "x!Q37_z*P" for example, in the JavaScript in the browser.
2. The browser takes the MD5 sum of the password: "5ebe2294ecd0e0f08eab7690d2a6ee69".
3. The browser then concatenates the password MD5 and the random string, with a carriage return between: "5ebe2294ecd0e0f08eab7690d2a6ee69" . "\n" . "x!Q37_z*P".
4. The browser takes the MD5 sum of that entire string: "ec1e557633decf2c14c306af381c9011"
5. Now the browser sends to the server the cleartext version of the random string, concatenated with a carriage return and the combined MD5: "x!Q37_z*P" . "\n" . "ec1e557633decf2c14c306af381c9011"
6. At the server end, we have the MD5 of the real password in the database. Retrieve that. Concatenate it with the one-time pad (the random string, easily extracted from what the browser sent) and CR. Then, take the MD5 sum of the whole thing. It should match what the browser sent after the CR.
This nonce or one-time-pad technique is very common in authentication schemes. It won't stop a playback or man-in-the-middle attack, but it *does* keep the actual MD5 of the password from being exposed. The only cleartext sent is the nonce, and the only MD5 sent is one that included the nonce in its creation.
The technique can be further refined by having the *server* supply the nonce string as a "HIDDEN" parameter in the login form itself, ignored by a non-JS client but used by the JS encryptor. The server then can keep track of the nonce values it has recently used, and only accept those values in submitted forms. Each time one of those nonces is used, delete it from the table in the server's memory, so that each nonce can only be used once by a POST operation. This effectively stops the playback attack, because the attacker would have to get back to the server *before* the client does, else that nonce will be already invalidated. And the attacker can't play back what it hasn't seen yet.
I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet.
Scott
-- Best regards, Herman Webley
!DSPAM:4372a353291217578633111!
You can build md5(challenge)+md5(password) if you have md5(password) but you can't build md5(challenge+password) which is what we would use. So they would need to know the unhashed password, not just its md5. Is that right? On 11/9/05, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
On Wed, 2005-11-09 at 16:46 -0800, Herman Webley wrote:
In the challenge-response they don't get in with md5($password), but rather with something like md5($challenge.$password), no?
Yes, but if the user has the md5 from the server, then he can build the $challenge.$password to submit to the server.
Gordon.
On 11/9/05, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
Not to put a spanner in the works, but I do not like the idea of being able to send an MD5 to the database. If they have compromised the database and have the original MD5, then they have a method of logging in without the password.
But then again, if they have the MD5, they can use some md5 crackers to get the original password.
Gordon.
On Wed, 2005-11-09 at 10:53 -0500, Syscrusher wrote:
On Wednesday 09 November 2005 10:29, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
Not necessarily. Assume a password of "secret", have the browser do this:
1. Generate a random text string, let's say "x!Q37_z*P" for example, in the JavaScript in the browser.
2. The browser takes the MD5 sum of the password: "5ebe2294ecd0e0f08eab7690d2a6ee69".
3. The browser then concatenates the password MD5 and the random string, with a carriage return between: "5ebe2294ecd0e0f08eab7690d2a6ee69" . "\n" . "x!Q37_z*P".
4. The browser takes the MD5 sum of that entire string: "ec1e557633decf2c14c306af381c9011"
5. Now the browser sends to the server the cleartext version of the random string, concatenated with a carriage return and the combined MD5: "x!Q37_z*P" . "\n" . "ec1e557633decf2c14c306af381c9011"
6. At the server end, we have the MD5 of the real password in the database. Retrieve that. Concatenate it with the one-time pad (the random string, easily extracted from what the browser sent) and CR. Then, take the MD5 sum of the whole thing. It should match what the browser sent after the CR.
This nonce or one-time-pad technique is very common in authentication schemes. It won't stop a playback or man-in-the-middle attack, but it *does* keep the actual MD5 of the password from being exposed. The only cleartext sent is the nonce, and the only MD5 sent is one that included the nonce in its creation.
The technique can be further refined by having the *server* supply the nonce string as a "HIDDEN" parameter in the login form itself, ignored by a non-JS client but used by the JS encryptor. The server then can keep track of the nonce values it has recently used, and only accept those values in submitted forms. Each time one of those nonces is used, delete it from the table in the server's memory, so that each nonce can only be used once by a POST operation. This effectively stops the playback attack, because the attacker would have to get back to the server *before* the client does, else that nonce will be already invalidated. And the attacker can't play back what it hasn't seen yet.
I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet.
Scott
-- Best regards, Herman Webley
!DSPAM:4372a353291217578633111!
-- Best regards, Herman Webley
Hi, On Wed, 2005-11-09 at 18:49 -0800, Herman Webley wrote:
You can build md5(challenge)+md5(password) if you have md5(password) but you can't build md5(challenge+password) which is what we would use. So they would need to know the unhashed password, not just its md5.
Basically I do not want this to open up other methods for compromise the system. You description is different to what is below, and I think may be ok.
Is that right?
I am not sure, but it is different from the description below. Gordon.
On 11/9/05, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
On Wed, 2005-11-09 at 16:46 -0800, Herman Webley wrote:
In the challenge-response they don't get in with md5($password), but rather with something like md5($challenge.$password), no?
Yes, but if the user has the md5 from the server, then he can build the $challenge.$password to submit to the server.
Gordon.
On 11/9/05, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
Not to put a spanner in the works, but I do not like the idea of being able to send an MD5 to the database. If they have compromised the database and have the original MD5, then they have a method of logging in without the password.
But then again, if they have the MD5, they can use some md5 crackers to get the original password.
Gordon.
On Wed, 2005-11-09 at 10:53 -0500, Syscrusher wrote:
On Wednesday 09 November 2005 10:29, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
Not necessarily. Assume a password of "secret", have the browser do this:
1. Generate a random text string, let's say "x!Q37_z*P" for example, in the JavaScript in the browser.
2. The browser takes the MD5 sum of the password: "5ebe2294ecd0e0f08eab7690d2a6ee69".
3. The browser then concatenates the password MD5 and the random string, with a carriage return between: "5ebe2294ecd0e0f08eab7690d2a6ee69" . "\n" . "x!Q37_z*P".
4. The browser takes the MD5 sum of that entire string: "ec1e557633decf2c14c306af381c9011"
5. Now the browser sends to the server the cleartext version of the random string, concatenated with a carriage return and the combined MD5: "x!Q37_z*P" . "\n" . "ec1e557633decf2c14c306af381c9011"
6. At the server end, we have the MD5 of the real password in the database. Retrieve that. Concatenate it with the one-time pad (the random string, easily extracted from what the browser sent) and CR. Then, take the MD5 sum of the whole thing. It should match what the browser sent after the CR.
This nonce or one-time-pad technique is very common in authentication schemes. It won't stop a playback or man-in-the-middle attack, but it *does* keep the actual MD5 of the password from being exposed. The only cleartext sent is the nonce, and the only MD5 sent is one that included the nonce in its creation.
The technique can be further refined by having the *server* supply the nonce string as a "HIDDEN" parameter in the login form itself, ignored by a non-JS client but used by the JS encryptor. The server then can keep track of the nonce values it has recently used, and only accept those values in submitted forms. Each time one of those nonces is used, delete it from the table in the server's memory, so that each nonce can only be used once by a POST operation. This effectively stops the playback attack, because the attacker would have to get back to the server *before* the client does, else that nonce will be already invalidated. And the attacker can't play back what it hasn't seen yet.
I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet.
Scott
-- Best regards, Herman Webley
-- Best regards, Herman Webley
!DSPAM:4372bb124452062717165!
On Wednesday 09 November 2005 21:49, Herman Webley wrote:
You can build md5(challenge)+md5(password) if you have md5(password) but you can't build md5(challenge+password) which is what we would use. So they would need to know the unhashed password, not just its md5.
Is that right?
Yes. -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
There are more issues with this JS md5-ing then just sniffing. * Browsers (or even better: operating systems, like KDE) store passwords. Javascript breaks this often. Leading to * insecure situations, because I have to write down the passwords. * People recieve paswords by mail. They sit in the (hotmail)inbox for ever. * People use way to simple passwords and re-use that everywhere. * People are lazy and naive by nature, when it comes to security. Give * them tough passwords, with rotation, and theyll stick post-its on * theyr screens. No, really, this could indeed live in a contrib! But for me it is senseless. Its like putting an expensive lock on your door that needs three keys (instead of the much quicker to use one) while all your windows are broken and the backdoor has no lock at all. Id say that false sense of security is worse then no security, since in the latter case, people are a little more carefull. So, make this a contrib, but mark it as "might help a little, but dos not make your site secure". Ber
On Thursday 10 November 2005 05:25, Bèr Kessels wrote:
No, really, this could indeed live in a contrib! But for me it is senseless. Its like putting an expensive lock on your door that needs three keys (instead of the much quicker to use one) while all your windows are broken and the backdoor has no lock at all. Id say that false sense of security is worse then no security, since in the latter case, people are a little more carefull.
So, because users are lazy (a point I freely grant) and browsers store passwords and the initial password has to be mailed in the clear, we shouldn't do anything to make Drupal itself less insecure? That's like saying, "I'm not going to bother putting a lock on my door, because somebody can break the glass in my windows and get in anyway."
So, make this a contrib, but mark it as "might help a little, but dos not make your site secure".
This, I strongly support. Your point about a false sense of security is quite valid, and we do need to make sure the docs for any contrib module clearly inform a novice sysadmin that the module won't "solve all the world's problems." Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
On Wed, 2005-11-09 at 10:29 -0500, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
I also agree with you that SSL is the ultimate solution if one really needs security.
However, I think that SSL in Drupal is an All Or None approach. Either the entire site is SSL, or not SSL. There is no way at present where only the login is https, and the rest is http.
If this is addressed, then the whole argument for these half baked solutions goes away: need security? Get SSL for login. Period.
Well here you go... its a bit of a kludge, but works. patched url() and l() to have an ssl flag... Minor touch ups to user.module. Sry this is against 4.6.3... I haven't started playing with the formsapi, or head yet... .darrel.
Darrel Thanks for taking the lead in this. Can you submit that as a patch against user module? This way more people will test it and comment on it. On 11/9/05, Darrel O'Pry <dopry@thing.net> wrote:
On Wed, 2005-11-09 at 10:29 -0500, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
I also agree with you that SSL is the ultimate solution if one really needs security.
However, I think that SSL in Drupal is an All Or None approach. Either the entire site is SSL, or not SSL. There is no way at present where only the login is https, and the rest is http.
If this is addressed, then the whole argument for these half baked solutions goes away: need security? Get SSL for login. Period.
Well here you go... its a bit of a kludge, but works. patched url() and l() to have an ssl flag...
Minor touch ups to user.module.
Sry this is against 4.6.3... I haven't started playing with the formsapi, or head yet...
.darrel.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09 Nov 2005, at 7:42 PM, Darrel O'Pry wrote:
Well here you go... its a bit of a kludge, but works. patched url() and l() to have an ssl flag...
I still think we should drop the 'external url' and / or 'ssl' qualifiers ( ) and then you can just make an alias for 'user/login' to https:// mysite.com/user/login' It's less places to change the code, as we already have a way to replace urls.would also be a useful way for networks of sites to configure their central login site. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDcjxzgegMqdGlkasRAmiLAJ0RNCEpK4vixmrLZE+N5IQuuAWHTgCgykTV plYjhP4AnkklIjjmQ1JjoCc= =W6zi -----END PGP SIGNATURE-----
On Wed, 2005-11-09 at 20:14 +0200, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09 Nov 2005, at 7:42 PM, Darrel O'Pry wrote:
Well here you go... its a bit of a kludge, but works. patched url() and l() to have an ssl flag...
I still think we should drop the 'external url' and / or 'ssl' qualifiers ( ) and then you can just make an alias for 'user/login' to https:// mysite.com/user/login'
It's less places to change the code, as we already have a way to replace urls.would also be a useful way for networks of sites to configure their central login site.
Khalid: I wanted to post it here before I put it in as an issue to see if there were better recommendations/approaches. Adrian: There is already a way to replace urls? Does Url Alias / path.module handle rewriting to absolute Urls?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09 Nov 2005, at 9:04 PM, Darrel O'Pry wrote:
There is already a way to replace urls? Does Url Alias / path.module handle rewriting to absolute Urls? If people would stop nitpicking and let us commit this : http://drupal.org/node/10888 And a small change during load (check the full url before checking the partial url)
This would also allow us to use pathauto to link all your forum posts to http://forum.mysite.com - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDclFkgegMqdGlkasRAgTCAJ9WuOyE0diuTEmHFzj+fO6DZE+lIwCeP1KB 9qibH+F9FIPJ9DxVltzWC6Q= =82HS -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09 Nov 2005, at 9:43 PM, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09 Nov 2005, at 9:04 PM, Darrel O'Pry wrote:
There is already a way to replace urls? Does Url Alias / path.module handle rewriting to absolute Urls? If people would stop nitpicking and let us commit this : http://drupal.org/node/10888 I should clarify that I don't like the final patch that was delivered.
I feel that url() should be smart enough to not break url's, without having to explicitly tell it what to do. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDclXSgegMqdGlkasRArFJAKChtVPwVhuWs8shQ5FKOOydD2vd8wCfSWko 4F94usoP5wMobtcLh2/Jk4w= =FZ7E -----END PGP SIGNATURE-----
On Wed, 2005-11-09 at 22:02 +0200, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09 Nov 2005, at 9:43 PM, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09 Nov 2005, at 9:04 PM, Darrel O'Pry wrote:
There is already a way to replace urls? Does Url Alias / path.module handle rewriting to absolute Urls? If people would stop nitpicking and let us commit this : http://drupal.org/node/10888 I should clarify that I don't like the final patch that was delivered.
I feel that url() should be smart enough to not break url's, without having to explicitly tell it what to do.
I agree with you wholly on that. I want my helper functions to make life easy for me with minimum fuss. I don't even like adding the $ssl flag that much. I'd rather have a mechanism for setting the protocol to be http or https per session. function get_protocol() { if (isset($_SESSION['protocol'])) { return $_SESSION['protocol']; } else { return variable_get('default_protocol','http'); } } //returns true on success, false on failure function set_protocol($protocol) { if (in_array($protcol, array('http','https)) { return $_SESSION['protocol'] = $protocol; } return false; } It means changing base_url to just a hostname, and updating url to accept a hostname which would replace the absolute variable and default to the hostname set in settings.php, and making it aware of get_protocol.
can't you do all this stuff in settings.php today? for example
if (isset($_SESSION['protocol'])) { $base_url = $_SESSION['protocol']. '//example.com'; } else { $base_url = 'http://example.com'; }
getting back to the topic, i'd love to see javascript hashing of password. this is used in phpmyadmin and many other projects. keyloggers have nothing to do with this. do folks think they are being smart when they post 'but this won't stop a keylogger'? no shit. that sort of post only serves to derail an otherwise useful conversation. please resist the temptation.
At 10:49 PM -0500 9/11/05, Moshe Weitzman wrote:
getting back to the topic, i'd love to see javascript hashing of password. this is used in phpmyadmin and many other projects.
I'm keen to work on this. I did a lot of work cleaning up the PHPLIB implementation of Challenge-Response logins and I'd like to set this up for Drupal. I'll try to set it up as a contrib module, that way the people who don't want it or don't understand the benefits don't have to install it :) ...Richard.
participants (12)
-
Adrian Rossouw -
Allie Micka -
B�r Kessels -
Chris Cook -
Darrel O'Pry -
Gordon Heydon -
Herman Webley -
Khalid B -
Moshe Weitzman -
Pat Collins -
Richard Archer -
Syscrusher