Vulnerability Development mailing list archives

Re: Cookies


From: Denis Ducamp <Denis.Ducamp () HSC FR>
Date: Wed, 9 Aug 2000 17:55:16 +0200

On Wed, Aug 09, 2000 at 11:30:36AM -0400, Kev wrote:
. the cookie (before md5) isn't guessable. If the cookie mustn't be based
  only on constants (username, userid, fixed secret password). The better is
  to choose a random number at each authentification.

the cookie contains a username, a flag, and an MD5 hash; as I say, I take
a secret stored on the server and do the md5 hash on that, the username, and
the value of the flag.

secret stored on the server and username and constant so if flag is constant
then md5(secret stored on the server, username, flag) is constant.

I don't know what is your flag, but I don't believe in data stored in the
client side. I prefer do get_session_data(cookie returned by user) and stock
everything in a local database where I get data I need depending on the
cookie returned by the user.

I don't see how a random number would be verifiable...
you'd have to put it in the cookie, and game over--unless you're going to
encrypt it, and if I were to go that far, I'd just use a cryptographic
signing protocol.

You have to maintain a table in the server side with the random number for
each actual connexion and make :
cookie = md5(secret stored on the server, username, flag, ..., random number)

But I prefer that the cookie is only a random number that change at every
session and which is the key that give me access to client data. As this
it's (neally) impossible to guest what is the cookie that is used by someone
else if you don't catch it on the network : the secret is that the cookie
mustn't be predictible.

Denis.

--
Denis.Ducamp () hsc fr -- Hervé Schauer Consultants -- http://www.hsc.fr/


Current thread: