7

The MVC Framework Symfony uses the following method in its creation of a remember me cookie:

/**
 * Generates a hash for the cookie to ensure it is not being tempered with.
 *
 * @param string $class
 * @param string $username The username
 * @param int    $expires  The Unix timestamp when the cookie expires
 * @param string $password The encoded password
 *
 * @return string
 */
protected function generateCookieHash($class, $username, $expires, $password)
{
    return hash_hmac('sha256', $class.$username.$expires.$password, $this->getKey());
}

So they use a string of the User Class, followed by the username, then a timestamp and then the user's password. It gets salted with a key that never changes and is equal for all the users throughout the system.

Now here is my issue with this: Why put the password in the cookie? Though it is the hashed, salted password (with another salt, unique for each user), isn't that an unnecessary risk?

Or am I being paranoid here?

Also, with that hash, it seems the only unique thing is the expires timestamp. Seems like it would be possible to copy some old cookies and create a new one for a replay attack right?

Update

The resulting Cookie is base64 encoded and its decoded content is:

Somenamespace\YourApp\YourUserClass:MjQ2NjM=:1501576079:74fbfcddcc66c2a11586bf4e39e68ddb459afa3a3fa6684e93d03fc393ee1141

The First Element is the User Class. The Second Parameter should be the base64 encoded username but this is what i get for it, so i guess it is the user id. I'll try to find out how that works too. The third Parameter is the "expires" Timestamp, so you don't even have to guess that. The fourth Parameter is said cookie hash.

Andresch Serj
  • 217
  • 1
  • 8

3 Answers3

3

This mechanism is so that when the user changes their password, all "remember-me" sessions are invalidated.

The two key features of this mechanism in regards to security is:

  • That the password cannot be determined from the hash in the cookie, if the attacker manages to gain access to the cookie somehow.
  • That the attacker cannot recreate the "remember-me" cookie using other data to gain access from another machine.

At first glance, because the cookie contains a hash of the password

Somenamespace\YourApp\YourUserClass:MjQ2NjM=:1501576079:74fbfcddcc66c2a11586bf4e39e68ddb459afa3a3fa6684e93d03fc393ee1141

it may appear that an attacker could brute force or "password guess" to find out if a tested password generates the same hash (4th parameter above). However, as this is a keyed hash (HMAC in this case), the attacker will not have the key in order to execute such an attack on the cookie value.

Regarding the second point, this is also hard for an attacker to accomplish for the same reasons. As the key of the hash is unknown, it will be almost impossible for an attacker to recreate the "remember-me" cookie even if user ID, class and expiry are known.

SilverlightFox
  • 34,178
  • 6
  • 73
  • 190
2

... Now here is my issue with this: Why put the password in the cookie? Though it is the hashed, salted password (with another salt, unique for each user), isn't that an unnecessary risk?

Risk assessment is on a case-by-case bases, so we can not say if its acceptable or not without further details on where its being used (and that's not a question for S.E.)

As pointed out the reasoning behind why the current password (in any form) is part of the hashing token used to add entropy, and to tie in the password with the token.

A similar token for a different password will therefor not work. This enables the system to "auto-logout" anyone when the password changes, without explicitly doing a logout and tracking all the "remember me" tokens.

The password itself should be in its hashed form (possibly salted), since we should never store unhashed passwords.

Or am I being paranoid here?

Yes, but is that a bad thing? ... what do the voices say??

Also, with that hash, it seems the only unique thing is the expires timestamp. Seems like it would be possible to copy some old cookies and create a new one for a replay attack right?

Well, no. as an attacker you would need the User name and the password to recreate a hash with to get a 'valid' attack token. you have bigger problems if the attacker has the username and password.

LvB
  • 8,943
  • 1
  • 30
  • 47
  • For replay attack no need for the username/password. Attacker has only to copy the cookie in his machine, then he find himself already logged-in when visiting the website. – elsadek Aug 01 '16 at 12:26
  • @elsadek: The Token does have an expire component in the hash thou so it probably isn't valid forever. – Andresch Serj Aug 01 '16 at 12:59
  • @elsadek assumption made (as by op) that some old cookie was used (not a huge leap to assume an expired one) – LvB Aug 01 '16 at 13:02
1

The only one reason I can see for adding the password param in the generated hash, is that when the user changes his password, the other persisted sessions in others computers will be terminated automatically.
This is also a good practice to force re-authentication with new password.

elsadek
  • 1,862
  • 2
  • 18
  • 55