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:
- Generated when hashing the password, so no additional cost or code
- Stored with password, so can find and match as necessary
The disadvantages may be:
- 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?