Is it secure to use bcrypt-generated salt in cookie to serve as token in place of a password?

Question

I have a (hobby) web site that runs only on SSL. The site does not deal with finances, social security numbers, or anything of that level of importance. However, I'd like to secure it as much as reasonably possible. Cookies are marked secure and httponly. Passwords are stored on the server-side using bcrypt.

I'm trying to implement "remember me" for those users who want to use it. Perusing this site, I know you don't want to store a password in a cookie; rather, you want to store a "token" which allows for non-critical use, but then prompt for the actual password for critical actions (e.g., changing the password).

Rather than randomly generating a token, then creating some database (or other method) of matching, is it too insecure to use the randomly generated salt from bcrypt as the token in the cookie?

The advantages are:

1. Generated when hashing the password, so no additional cost or code
2. Stored with password, so can find and match as necessary
3. Unique

The disadvantages may be:

1. Token does not change from session to session

If the cookie is somehow stolen, it allows only non-critical access to the site. That is, it doesn't reveal the actual password, the password can't be changed, the email associated with the account can't be changed.

Am I overlooking anything serious in the above scheme?

Answer 1

My two cents, you are not overlooking anything. Your scheme is correct. But do mind that what you are doing is not secure. The session id should be unique for every sessions. Why you may ask?

Well suggest an attacker is able to steal the cookie. Then he can log in as that user. Until the user logs out, because then the session id expires. However if your session id remains the same through all your sessions, the attacker will be able to keep logging in as the user, regardless of the user logging out or not.

In short this means, once an attacker has stolen a cookie, he will have a permanent key for that user's sessions (unless the user changes password). Do realize that this is considered a high risk. The impact of such an attack can be rather high.

Answer 2

Do not do this.

If an attacker were to sniff the session ID over the wire, the attacker now has effectively permanent access to the user's account. Equally as bad, you have no way to expire the session if you do know this has happened since you can't regenerate the bcrypt digest without having the user's password.

Don't try to be creative. Generate a random token on every new visit, and regenerate it on login to avoid session fixation attacks (where an attacker sets a user's session ID to a value he knows, then waits for the user to log in before accessing the site with that ID).

Answer 3

In addition to the answers above, dealing with the need of session tokens to be random and different for each session, there is also another risk in publicly exposing the salt of a password hash.

While it is true that a salt is not meant to be secret, it is at the same time not a good idea to make them publicly known. This is because an attack who knows the salt, can build a rainbow table for this particular salt, prior to obtaining a copy of you hashed passwords.

When he does get the copy of the hashed passwords (for example by a SQL-injection attack) he can now immediately attempt to lookup the value of the hash he has already build the rainbow table for. Thereby minimizing the time between the attack and the actual malicious usage of the stolen data.

Polynomial has answered this better than I can.