Re: protecting passwords when SSL is not available

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You are absolutely right!  I love this list!

I didn't realize that I was sending the session_id. Let's see if this works.

On first serving the login page I create a session and also a unique_id via uniqid(). I store the unique_id in the session and send it as a challenge to the client along the login form. This unique_id is the nonce. Upon receiving the login data and checking it for good, I delete the unique_id from the session. If I receive a made up session_id, the password data won't match the unique_id stored in the session (probably there will be none). The nonce stored in the session will be a new one, even for the same session, each time the login screen is requested. If the login fails, upon retry a new unique_id will be generated and sent for the retry. Thus, session_ids and unique_ids combinations (almost) never get repeated. Thus, is you knew the answer to one, it won't help you with any other because even if you can make up a session_id, you cannot change the unique_id the server made and, since unique_ids don't repeat, there is no chance that you have ever sniffed the password hashed with that unique_id.


Satyam


----- Original Message ----- From: "Evan Priestley" <spam@xxxxxxxx>
To: "Satyam" <Satyam@xxxxxxxxxxxxx>
Cc: <php-general@xxxxxxxxxxxxx>
Sent: Monday, March 27, 2006 11:58 PM
Subject: Re:  protecting passwords when SSL is not available


The client cannot and does not send the session_id() used to hash the password back to the server, it does not need to, the client got it from the server.

It does send the session ID back though, because that's how the user maintains their session across requests.

For simplicity, let the totally made up word "noncehash" represent hash(hash(password)+nonce) -- that is, the hash of 'the nonce appended to the hash of the password'.

Generally, if the client ONLY sends (a) a user name and (b) a noncehash, then the server has no way to tell which nonce was originally issued. Therefor, the client has to send (a) a user name, (b) a noncehash, and (c) some key which can identify which nonce was sent. This key might be the session ID, the nonce itself, or something else[1].

If the key is the nonce itself and the only server-side validation is that the response noncehash is correct for the supplied nonce, attacker Bob can observe ANY valid nonce/noncehash combination Alice submits and replay it to gain access[2].

If the key is the session ID, and the only server-side validation is still that the response noncehash is correct for the given session ID, attacker Bob can STILL observe ANY valid session ID / noncehash combination Alice submits (she _is_ submitting the session ID -- the nonce, here -- because every request always includes the session ID when sessions are being used) and replay it immediately to gain access. This is "session hijacking", and it works because PHP will let Bob into Alice's session as long as he knows her session ID[3].

Instead, suppose the server-side validation is a little stronger: it checks that the response noncehash is correct for the given session ID, but ALSO checks to make sure that this session ID hasn't logged in yet. Now Bob can't replay the response immediately. He can still just hijack the logged-in session, though, and he might be able to replay the attack after Alice's session has expired, because the flag that says "this session has already logged in" will also have expired. I'm not sure if PHP will create an expired session ID for you; presumably it won't, but if you're writing your own session handler or implementing nonced password transmission in some other programming language, this might be a viable attack vector.

Evan

[1] It could even be the username, if the login process went like this: client sends server username, server generates a nonce and stores it in the user table, server sends generated nonce to client, client sends hash(hash(password)+nonce) to server -- but then an attacker can perform a DOS attack by repeatedly sending the server a username so that it regenerates nonces more quickly than the real user can log in. In any case, (a), (b) and (c) do not necessarily need to be three separate pieces of information, since one piece of information can serve multiple roles. [2] Unless nonces are stored in a database and flagged as "used" afterward. You can also, e.g., generate nonces in the form "timestamp,hash(timestamp+secret)"; google for more on this. [3] Unless you're e.g. restricting sessions by IP, but this is potentially a whole different can of worms.



It is the server that challenges the client with a session_id() (or any other random) sent clear and the client has to take the challenge and combine it with the password (which is not transmitted clear). Thus the client cannot tell the server, 'this is user xxx, with password yyyy hashed under session_id zzzz'. It is the server that challenges the client with the session_id. The attacker might collect enough samples so if a challenge repeats, he can have the answer ready, but that is unlikely with long enough challenges (and session_ids are long).

As for sending the session_id() from the server to the client in clear (not encrypted) it seems to me it doesn't make any sense to alter it in any way since, after all, you are also sending the algorithm in Javascript to the client, which is clear for anyone to see, so there would be no point in trying to hide the session_id in any way, and I don't think it would help the overall security.

My bank does use SSL, of course, and it still requires confirmation to do critical processes so, that might be a partial solution to spoofing.

Anyway, this is a poor man replacement for SSL, with limitations, but it is good to know what are those limitations.

Thanks for your help

Satyam



----- Original Message ----- From: "Evan Priestley" <spam@xxxxxxxx>
To: "Satyam" <Satyam@xxxxxxxxxxxxx>
Cc: <php-general@xxxxxxxxxxxxx>
Sent: Monday, March 27, 2006 5:41 PM
Subject: Re:  protecting passwords when SSL is not available


This is called a "nonce"[1], and the method you've described will give you marginally less awful security than submitting a plaintext password or an unadulterated hash of the password, but, obviously, is in no way a substitute for real SSL. For instance, if this password puts the session in a "logged in" state, an attacker with the capacity to sniff the password can also sniff the "logged in" session ID after authentication. You can potentially bind the login to IP, but will prevent users behind rotating proxies from using your service and may not protect users behind non-rotating proxies, and the source IP for a request can be spoofed. Alternatively, you can require the password for any action requiring authorization (and never put the user in a "logged in" state), but this will impose substantial constraints on your design. And, of course, an attacker can still observe any other data you transmit.

If you implement nonced password transmission, absolutely ensure that an attacker can not alter the provided nonce. For instance, if Bob sees Alice log in under nonce "abc123" (her PHP session ID), what happens if Bob later executes a replay attack by mimicking her form submission (username: alice, password_hash: def456, session_id: abc123)? If he can gain access via replay attack at any time after Alice's first login ([a] while her session is valid or [b] after it has expired presumably being the critical periods), the system offers no security over non-nonced password transmission.

Evan

[1] http://en.wikipedia.org/wiki/Nonce

On Mar 27, 2006, at 8:30 AM, Satyam wrote:

I know the answer to a secure site is SSL, but what if you are on a shared host, SSL is unavailable and you still want some sort of security?

This is what I came by and I would appreciate any advice as to possible security holes in it. There is a big hole I know, which is the screen to change the password, I find no way to secure that one. But lets go to what I do have.

I found at http://pajhome.org.uk/crypt/md5/md5src.html a Javascript version of the MD5 algorithm.
I checked it against the PHP md5() function:

<html><head><title>MD5 test</title>
<script language="JavaScript" src="includes/md5.js"></script>
<script>
function enOnLoad() {
document.getElementById('prueba').innerHTML = md5_vm_test(); // test provided by the library
 <?php
  $valor = rand();
 ?>
 document.getElementById('p2').innerHTML = hex_md5('<?=$valor?>');
}
</script>
</head><body onLoad="enOnLoad();">
<div id=prueba></div>
<div id=p2></div>
<div><?=md5($valor)?></div>
</body></html>

And the results of the Javascript and the PHP md5() functions are the same (the JS source has a couple of parameters to play with, but the defaults proved good enough)

So, my idea is that in the login script, PHP will send a random number along with the login form. That random might actually be the session_id() but if not, the random value sent has to be stored in a session variable. (I really don't see any reason not to use the session_id()).

On clicking on submit to send the login form, the password field would be replaced by the result of

a) calculate the MD5() of the password, trimmed of whitespace. This should be the same value stored in the user table of the database. b) concatenate this value with the random number (or session_id ()) provided by the server.
c) calculate the MD5() of this
d) replace it into the original password field and let the submit proceed.

On the server side, when the login data is received:

a) retrieve the password field from the user table on the database. This should actually be the MD5-encripted of the actual password. b) concatenate this value with the session_id() or whatever random you generated before
c) calculate the MD5() of this
d) compare with received value. If they match, they come from the same password.

Would it work?

Satyam

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux