Chicken and egg issue with Cookie based login?

From: Julio (
Date: 04/06/05

Date: Wed, 6 Apr 2005 04:39:25 -0400

I have few questions I hope someone can clear up for me with the cookie
security discussion at this W3C document:

 I'm trying to implement a cookie based authentication system for our
private web server. The document suggested a popular algorithm/method to
generate a MAC.

MAC = MD5("secret key " +
           MD5("session ID" + "issue date" +
               "expiration time" + "IP address" +
               "secret key")

It also says this about the secret key:

    "This algorithm first performs a string concatenation of all the data
    fields in the cookie, then adds to it a secret string known only to the
    Web server."

My questions are:

How is this a "secret" only know to the server if its needs to be passed to
the client in order to generate the hashed cookie? Sounds like a chicken
and egg scenario, since you need to contact the server to get the secret key
in the first place?

Second, would be an example of the "Session ID" or more general, what is an
example for a secret key and session id for a system that users a
username/password database on the server side?

if my web server has a built-in user database storing a user name and
password, and the typical login form for a web page would be for a
userid/name and password prompt, it seems to me that this "Session ID"
could be the combo of the userid/password? or....

Since this is a hash, there needs to be some unhashed value passed to the
server, like the user name and only include the password (Session ID?) in
the hash in order to do the username lookup and perform a hash comparison
with the password?

Is the "Secret Key" the user's password and the Session ID the user's name?

Finally, what I came up with (to explore) is this:

MAC = MD5(password +
           MD5(userid + sessionkey + password) )

where sessionkey is unique hash key for the new login session. It contains
the following:

    sessionkey = MD5(IP + unique counter + timeout window)

All 3 parameters are cached at the server mapped to the sessionkey.

Next the cookie is set:

COOKIE = username + ":"+ sessionkey+":"+MAC

At the server, the username is looked up to get the user's database
password, and the sessionkey is looked up to get the 3 session parameters.
The appropriate checks are then performed; the IP is compared; the timeout
window is checked, and the MAC is regenerated based all the server ready

I know its not 100% fool proof, but does this make sense?

Currently our web server supports BASIC and DIGEST (and SSL), so of course,
if anyone is concern with security, they are steered to enforcing SSL or
atleast DIGEST for non-SSL operations. The cookie support has been a big
request mainly to offer the complete log off capability lacking in standard

So I want something with cookies that is atleast better than plain text
BASIC using a similar "session key" challenge concept as done with DIGEST.

Make sense?


Relevant Pages

  • Re: web replication
    ... Session cookies relate to memory in the server, ... cookie, then yes it's a problem if one cannot be certain of which box ... , i'm actually studying the lvs documentation, ipvs via nat use nat to ...
  • Re: tracking logins
    ... You might wonder how after the login is complete that the server can ... By TCP/IP session. ... The server sends a cookie at login time, ...
  • Re: $_SESSION problem - page reload creates new Session ID
    ... > set on a page just viewed because there is a new session created ... As fas as the server is concerned all requests are independant. ... cookie back to the server. ...
  • Re: Asp| Cookies vs Session Variables
    ... An in-memory cookie is stored in the client's memory. ... Session variables themselves aren't a particular burden on a server. ...
  • Re: ASP IIS Session Hell
    ... Sessions are maintained by cookies passed between the server and browser. ... If the server is not sending the session cookie, ... 3 sites off a common folder, ...