Page 2 of 2

Posted: Wed Jun 15, 2005 4:46 pm
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?

Posted: Wed Jun 15, 2005 4:55 pm
by John Cartwright
The user's ID can be easily guessed though..

Posted: Wed Jun 15, 2005 5:54 pm
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“

Posted: Wed Jun 15, 2005 8:17 pm
by McGruff
MAC: I might be able to guess your encryption algorithm - unless you rolled your own - but I never know your private key.

Posted: Thu Jun 16, 2005 1:19 am
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.

Posted: Sun Jun 19, 2005 1:27 pm
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.