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.

  • 1
    Please include the code snippet that shows the actual contents of the Cookie. – Jacco Aug 1 '16 at 9:58
  • @Jacco: I have added it. – Andresch Serj Aug 1 '16 at 10:05
  • Which cookie are set? The output from generateCookieHash as well as the decoded content you pasted? As separate cookies or within the same value? – SilverlightFox Aug 1 '16 at 14:05
  • @SilverlightFox It is all in one cookie, the one i posted, only that the content is base64 encoded. – Andresch Serj Aug 1 '16 at 14:39
  • Where does the return value from generateCookieHash end up? – SilverlightFox Aug 1 '16 at 14:41
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.

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.

  • 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 1 '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 1 '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 1 '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.

  • First: This doesn't answer weather or not it is safe. Second: Wouldn't it be easy to change the token stored for the user when said user changes the password? – Andresch Serj Aug 1 '16 at 11:06
  • 1
    @AndreschSerj you asked indeed "Why put the password in the cookie?" – elsadek Aug 1 '16 at 11:16
  • My Mistake to ask two questions in one :D – Andresch Serj Aug 1 '16 at 11:18
  • @AndreschSerj, much better then token, this a smart approach to handle the "remember-me" without additional complications. – elsadek Aug 1 '16 at 12:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.