Best way for hashing a "remember me" cookie token

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://mcmap.net/q/45367/-how-do-you-use-bcrypt-for-hashing-passwords-in-php-duplicate

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?

Jackfish

possible duplicate of What is the best way to implement "remember me" for a website? – Accumulation

Using a hash is an expensive waste of time for this - use a random value – Accumulation

Best practice docs/anwsers/articles strongly recommend to hash the token in DB ; I'm simply looking for advice on an appropriate way to do that. – Jackfish

IME, when people start mentioning "best practice" it usually means they don't know what they're talking about. But yes - I see you're talking about the value stored in the database - not the cookie value. So there is a risk of replay attacks if the database is compromised. But this pre-supposes that you allow 'remember me' to persist across different IP addresses / browser fingerprints. – Accumulation

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.

Jackfish