Question

I’ve just read the following:

And DO NOT STORE THE PERSISTENT LOGIN COOKIE (TOKEN) IN YOUR DATABASE, ONLY A HASH OF IT! The login token is Password Equivalent, so if an attacker got his
hands on your database, he/she could use the tokens to log in to any
account, just as if they were cleartext login-password combinations.
Therefore, use strong salted hashing (bcrypt / phpass) when storing
persistent login tokens.

(in this answer: https://stackoverflow.com/a/477578/943102)

I thought that hashing is supposed to be used because people use the same password on multiple sites and it prevents the attacker from breaking into other accounts of the same user. Since the login token is a random value, this risk is not present in this case. I’m obviously missing something but I couldn’t find any further information about this. Can somebody explain?

Answer 1

Let’s suppose that you’re a web application developer and you do the right thing and you only store hashes of your users passwords in the database (not plaintext), but you decide to store their authenticated login tokens in the database without hashing them.

Now suppose a malicious attacker breaks into the web application’s database and does a dump and shares it with his malicious attacker buddies on the web. Well, those password hashes won’t do him much good, because he can’t log in with a hash. But he sees those login tokens are stored in plain text. Now it’s trivial for him to put one in a cookie and send it along with a HTTP request to the server. The server will take the cookie, authenticate it against the database, and allow the attacker in. So even though those login tokens are just random values, once the attacker has them, he or she can use them to impersonate the authenticated user.