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
