Best Practices for "Remember Me"?

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Swede78
Forum Contributor
Posts: 198
Joined: Wed Mar 12, 2003 12:52 pm
Location: IL

Post by Swede78 »

Well, both can be done quite randomly and uniquely. If you use Neilsene's method,
identifier+expTime+MAC(identifier+expTime),
it takes a bit of extra work to ensure the identifier is not easily guessable. To do this, you have to add a field to your user account table, that stores a unique, but random string. As he suggests...
I tend to recommend a hashed random value for use as the identifier -- store it in the DB, not used as a key elsewhere
This method now becomes quite a bit more complex than simply encypting the user's ID, which frees you of storing any info in plaintext. I guess one drawback of encrypting a user ID, is that you can't easily change the key without everyone having to log in manually. Any other drawbacks?
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

The user's ID can be easily guessed though..
Swede78
Forum Contributor
Posts: 198
Joined: Wed Mar 12, 2003 12:52 pm
Location: IL

Post by Swede78 »

How? If all you store in the "remember me" cookie is a encrypted string of the user ID, you would have a string looking something like this, depending on what type of encryption you use:

Encrypted UserID = ËTßkÛñ#Y¹w“
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

MAC: I might be able to guess your encryption algorithm - unless you rolled your own - but I never know your private key.
Syranide
Forum Contributor
Posts: 281
Joined: Fri May 20, 2005 3:16 pm
Location: Sweden

Post by Syranide »

Would it really matter? He would be almost as powerful with that ID as with the password and username, as both grants him access. (There is no way of making the cookie secure, as the information in the cookie will always signin the user)

The only thing I guess is using fingerprinting, but that will have other setbacks as switching browser, or such.
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

The reason I recommend a hashed random value is to protect against a directed attack. Obviously a stolen/intercepted token is able to attack the user it came from, without draconic IP ties.

If the token ID has NO relationship to the userID that it belongs to, save the hash in the DB, then even if the attacker manages to crack the signing secret key used in the HMAC, he can't compute the needed ID for another, different users -- say a known higher priviledge person.

As a further protection, I think (haven't really thought through this one), you could probably also send the username now with the token, for a cookie payload like
userid+username+expTime+HMAC(userid+username_expTime)

to avoid the possible attack of just generating random userids and submitting them. This would also slightly simplify the creation of the userid hash at cookie creation time as it does not have to be unique in the database.
Post Reply