hashed username and password in remember me token?
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.
... 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.