|
Posted by Barry Margolin on April 6, 2005, 8:52 am
If you were Registered and logged in, you could reply and use other advanced thread options
> I have few questions I hope someone can clear up for me with the cookie
> security discussion at this W3C document:
>
> http://www.w3.org/Security/Faq/wwwsf2.html#CLT-Q10
>
> 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?
Cookies are created by the server, not by the client. Clients just
receive the cookie, save it away, and return it to the server with all
future requests. The server generates the hashed cookie and sends it to
the client.
>
> 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....
What if you want to allow the same user to login concurrently from
different clients (e.g. a husband and wife both checking their bank
account balances)? You need to use something unique to a particular
login, not just identifying the customer. You can just use a counter,
incrementing it every time a login comes in.
>
> 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?
The secret key should be a random value generated at login time; if it
were the user's password, it wouldn't be known only to the server, it
would also be known by the client.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
|