Question

I’m trying to implement a “remember me” feature, following the guidelines provided here: The definitive guide to form-based website authentication, and here: http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/

It appears that the “cookie token” should be hashed when stored in DB (if an attacker has access to DB, unhashed tokens look like plain login/passwords, allowing to log in on the website).

Looking for a good hashing algorithm, I’ve found this recommended technique using bcrypt: https://stackoverflow.com/a/6337021/488666

I’ve tried it and found that with the amount of rounds proposed (15) leads to a very slow processing time (hash 2,3s + verify 2,3s on an Intel Core 2 Duo E8500 + 4 GB RAM)

I know that hashing algorithms should be relatively slow to hamper attackers, but at that level, it hampers users to use the website 🙂

Do you think that less rounds (e.g. 7, which drops processing time to 10ms + 10ms) will be enough?

Answer 1

Quoting The definitive guide to form-based website authentication:

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 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.

I agree with the first bold sentence, but not the last one.

If I’m not mistaken, the purpose of a “strong salted hashing” algorithm is that someone should not be able to retrieve passwords given a rainbow table.

But here, the hashed string is not a password but a random string. Therefore it’s pretty unlikely that any rainbow table would be able to retrieve any originally hashed string. I even guess that I simply could use a basic hash('sha256', $randomString) call for this, the goal being to have different values for the token in the DB and in the cookie.