Re: Cookies

[Kev <klmitch () MIT EDU>]

> . 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.  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.

> . a cookie generated for an IP A can't be used by an IP B ?
>   Difficulty : if the user is behind a proxy that doesn't give the client IP
>   then another client behind that proxy may use that cookie.
>   Other data as client software and version may be part of verified data.

No, I didn't think to include IP verification, so it is vulnerable to a
replay from another IP; thanks for pointing that out, I'll remember it in
future applications...

> . when a cookie is generated for a user, that user doesn't have another
>   cookie yet ?

Nope.  I should also put an expire time on the cookie...

> . a cookie received by the server hasn't exceeded its time to live ?
>   The user have to reauthenticate himself regularly during a session.
>   The cookie must disapear when the client is closed.

Yeah, I'm using unlimited expire on the thing right now.  I do have to
reauth when I restart the browser, though...thankfully, this is behind
the corporate firewall, but...
--
Kevin L. Mitchell <klmitch () mit edu>