how to properly secure non-ssl logins (php + ajax)

[Joseph Ashwood]

----- Original Message ----- 
From: "Rene Veerman" <rene7705 at gmail.com>
Sent: Sunday, February 15, 2009 4:30 AM
Subject: how to properly secure non-ssl logins (php + ajax)


I'm going to edit this, since I assume most of the code is completely 
irrelevant

proposal:
database stores Hash(password | salt) on server
challenge = Hash(random bits), challenge specifically does NOT change every 
time
user_hash = Hash( Hash( password | salt) | challenge)

There are so many ways to attack this I'm not sure where to begin:
1) Man-in-the-middle - user <-> Jerk <-> server, Jerk can easily highjack 
the session
2) Fake server sends out known predictable challenges, user is now an oracle
3) hack the real server, retrieve Hash(password| salt) hacker can now log in 
to server FASTER than user
4) hash attacks, you mention specifically that MD5 is available as a hash 
for this, DONT EVER USE MD5

the list continues


Now how to (mostly) fix it:
g, p, q are DSA parameters of sufficient size
Hash is a secure Hash, SHA256 will work, but SHA512 will work faster
database stores g^Hash(password | salt) mod p, call it gUser
Challenge = time | random bits, make it 256 bits, using time reduces the 
number of random bits used
gChallenge = g^Challenge mod p
Signed-gChallenge = cryptographically signed gChallenge | time, this does 
not take a certificate, just a trusted known signature key

Client receives  Signed-gChallenge and salt
Client verifies signature including time on Signed-gChallenge and extracts 
gChallenge

Client computes Y = gChallenge^Hash(password | salt) mod p
Server computes Y = gUser^Challenge mod p

If Y=Y client knows the password. For proof of security, this is signed-half 
ephemeral Diffie-Hellman key agreement with reveal.

1) This does not fix the MITM attack, only an encrypted tunnel can do that, 
so use SSL
2) Fake server only repeat a challenge created by the real server because of 
the signature, but the public key of the signing key needs to be verifiable, 
this is where certificates come in
3) Retrieveing gUser from the database is exactly identical to retrieving a 
Diffie-Hellman public key, no risk, database can be public
4) ALWAYS REMEMBER TO NEVER USE MD5

Also with SSL you don't need to have a paid for certificate, have a look at 
https://financialcryptography.com/ for an example.
                Joe 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com