MoinMoin: MoinMoinTodo/Release 1.1/PasswordAuth

current algorithm under discussion

Good properties:

• The plain text of the password never goes over the wire

• The server never knows the password -- it only knows md5(password). ¹

not-so-good properties:

• md5(password) goes out over the wire. And that's all an imposter needs. (But this only happens once, on registration).

Registration:

• on registration, client calculates md5(password) and sends it to the server, which stores it.

Login:

1. when the client tries to log in, server sends a random challenge to the client
2. client builds md5(challenge + md5(password)) and sends it to the server
3. server creates the same md5 hash as the client and compares it to the one it received.
   • fast: the client sends its public user name in the same message -- the server builds 1 md5 hash corresponding to that user and compares it to the recieved hash.
   • slow but anonymous: the server builds n md5 hashes for n registered users, and comparing each to the received hash. But as md5 is quite fast, this should not be a problem, even for large number of users. We are talking about login? So performance is not important!
4. as response to a successful login, set a one-time-cookie (see below)

Session:

1. Server sends a one-time-cookie (randomsequencenumber) to the client and saves this also to the user account record. The message includes (randomsequencenumber, salt, md5(randomsequencenumber,salt,md5(passwd))).
2. Client checks the md5, and if valid, client stores that cookie and uses it for next request.
3. When Client wants to send a request, it sends (request, md5(randomsequencenumber, md5(passwd), request)).
4. Server checks the md5 and, if valid, carries out the request and sends out a new one-time-cookie.

early versions

antifuchs and ThomasWaldmann discussed this login scheme on IRC today [sometime before 2004-05-24] (which is unimplemented yet involves no passwords going over the wire except once, on signup):

Registration:

• on registration, server receives the user's password and stores md5(password)

Login:

1. when the client tries to log in, server sends a random challenge to the client
2. client builds md5(challenge + md5(password)) and sends it to the server
3. server creates the same md5 hash as the client and compares it to the one it received.

   • this involves building n md5 hashes for n registered users, and comparing each to the received hash. But as md5 is quite fast, this should not be a problem, even for large number of users. We are talking about login? So performance is not important!

4. as response to a successful login, set a one-time-cookie (see below)

How is the md5 passwd stored securly? Couldn't a fake Server read the cookie containing the passwd md5? What if the user looses the md5-cookie. Then the passwd and the md5 hash must be tranfered over the net again - in plain text!!!

Session:

1. Server sends a one-time-cookie = md5(uid,randomsequencenumber) to the client and saves this also to the user account record
2. Client stores that cookie and uses it for next request:
3. Server gets the cookie and does a lookup into the accounts searching for that one-time-cookie
4. Server sends a new one-time-cookie ...

If such a session gets intercepted and somebody else uses the cookie, the correct user will lose the session. If he logs in again (using his password as described above), the interceptor will lose the hijacked session again.

The session is vunerable to a man-in-the-middle attack! Once the attacker reads a coockie he can intercept the connection, talk to the server and fake the answers for the user by using the hijacked connection. To make the connection secure the secret (md5sum of passwd) must be checked for every request. -- FlorianFesti 2003-07-21 06:39:59

• IMBW, but I think there a conflicting interests here. One can provide a secure authentication mechanism using the process discribed above (hash+nonce)². But providing a secure session using only this mechanism is not a good idea - that's what SSL is for. To provide a soft security here one could put short timelife on the cookies and requesting the user to re-login every time he is about to modify his profile or sensitive data. -- TiagoMacambira 2003-08-14 17:58:43

what about

1. Server sends a one-time-cookie (randomsequencenumber) to the client and saves this also to the user account record
2. Client stores that cookie and uses it for next request:
3. Client calculates md5(randomsequencenumber, md5(passwd)) and sends it with the next request
4. Server compares the value from client with selfcalculated md5(randomsequencenumber, md5(passwd))
5. Server sends new randomsequencenumber

Possible attack: intersept connection, wait for a request that can be answered without user rights. Get the answer as anonymous and send it back to the user and use the randomsequencenumber for own purposes. Send back the new randomsequencenumber to the user with the answer. Solution:

• Server sends (randomsequencenumber, salt, md5(randomsequencenumber,salt,md5(passwd)))
• Client checks the md5 and sends md5(randomsequencenumber, md5(passwd), request)
• Server checks md5(randomsequencenumber, md5(passwd), request)

Logout:

• remove cookie, invalidate cookie in useraccount

Not needed with the protocol above.

General Problem: Heavy use of md5(something, md5(passwd)) generates data for a possible brute force attack against md5(passwd). I don't have enough knownleged about cryptographie and md5, to have any idea if this is a real or a theoritical problem.

Using public md5 hashes of passwords is vunerable to a dictionary attack:

   1 for word in dict
   2     if md5(randomsequencenumber, md5(word), request) == captured_md5:
   3         result = word
   4         break
   5 print result

http://selfaktuell.teamone.de/artikel/javascript/wertuebergabe/index.htm

http://selfaktuell.teamone.de/artikel/javascript/wertuebergabe-2/index.htm

http://selfaktuell.teamone.de/artikel/javascript/md5/index.htm

Is this perhaps reinventing the wheel? I found this site to contain some useful guidance on the do's and don'ts of Web authentication: http://cookies.lcs.mit.edu/pubs/webauth.html

Nice. Just some keywords of it:

• use temporary cookies not being saved to disk
• prevent cookie lifetime extension by including a cryptographically unalterable timestamp into the cookie

• cookie = expire=<t>&data=<d>&digest=MAC(expire=<t>&data=<d>, secretkey)

"On Choosing Encryption ..." http://slashdot.org/article.pl?sid=00/06/07/2250201 discusses the most popular encryption algorithms, and how to choose one.