Something I used was this:

id | username | password | cookie_string

$foo = the id was rot13'ed then base64-encoded

$str = the cookie_string was an md5 hash generated at the time of registration

then a cookie was set:


When the user returns, we checked for the cookie, and if it existed, split
on the "|", de-"crypted" (haha) the ID, looked up the cookie_string in the
DB and saw if it matched.  If it did, it was pretty unlikely that it was
"hacked" so we logged them in.


On Wed, 4 Dec 2002, Jim wrote:

> > Always, always, always use a value that has no other significance other
> > than being a unique ID. Email addresses change and so do passwords, so
> > those are poor choices for linking data. They are fine and good choices
> > for login, but that's about the only thing they should be used for.
> I understand what your saying, but if I just use the ID, then it makes it
> extremely easy to login as another user, simply change the ID in your
> cookie. Atleast if I have email/password aswell it takes someone with access
> to the network and a sniffer to get the values.
> If a user changes his email and/or password, then the cookie gets updated,
> simple. I can't see that its that much of an issue. If we were talking about
> a credit card number or something else critical then I'd agree.
> Jim.
> --
> PHP Database Mailing List (
> To unsubscribe, visit:

Peter Beckman                                                  Internet Guy
[EMAIL PROTECTED]                   

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to