|
|
|
|
|
by munk-a
38 days ago
|
|
Cookies, if done correctly, will store a string that the server offered after a successful authentication - that string should have nothing to do with the password (it might contain some user information for logging/cross site tracking) but nothing sensitive. With said cookie you can absolutely impersonate a user for while (potentially needing to evade user agent string checks and the like but often not)... but it will expire and then your access should be ended. If the site is well designed actions like password changing should also re-require the user's password instead of allowing anyone with just the cookie from proceeding with the action. If it is done right cookies are pretty decently secure at keeping your secrets safe but, for convenience they do lower the security that could be accomplished with more involved techniques. As an aside Oauth's key -> token approach is basically identical to password -> cookie (assuming best practices are in place). |
|
Google now wants to bind credentials to a device by storing the secret in the TPM: https://blog.google/security/protecting-cookies-with-device-...