8

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?

RPW
  • 93
  • 1
  • 4

3 Answers3

7

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.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • +1, NEVER do this. Session hijacking is a very real threat. –  Sep 30 '12 at 01:48
  • Thanks for the reply. I was looking at the likelihood of the cookie's being stolen on the one hand (remember, it is all SSL, secure, httponly, etc) vs. the relative unimportance of what is being protected on the other hand. And if you'll allow me a third hand, the relative effort in coding (remember, this is a hobby, not a day job or even a paying job). – RPW Sep 30 '12 at 10:30
4

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

Stephen Touset
  • 5,736
  • 1
  • 23
  • 38
1

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.

Community
  • 1
Jacco
  • 7,402
  • 4
  • 32
  • 53