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:
setcookie("cookie_string",$foo."|".$str);
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.
Peter
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 (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman@purplecow.com http://www.purplecow.com/
---------------------------------------------------------------------------
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
