It seems that persistent logins are technically the same as storing a password on the client, and therefore should be avoided whenever possible. However, real life users would be unhappy with having to enter their password every time they wanted to access a site that they visit frequently.

Given the following assumptions:

  • All traffic is over SSL, so that physical access to the client is required to gain any stored login token
  • Passwords are hashed via BCrypt/PBKDF2 before being stored

What are the security implications, if any, of taking the password hash, hashing it again using salted SHA512 and using the result for the persistent login token? Verification of the login token would be by comparing the token against a hash of the password hash.

The reason I'm asking this is that I'm trying to avoid storing a separate token in the database for the persistent login.

  • 1
    So then you are logged in until you change your password? I like the fact that tokens can be invalidated whenever the need arises. WHY are you trying to avoid a separate token? – Darsstar Mar 15 '14 at 18:45
  • Because users could be logged in from more than one location (phone, PC etc.) the database would have to store multiple tokens for a single user. So I was trying to save having to write a record to the database on login and needing to do a lookup in an additional table to verify the login. – Jon Benedicto Mar 15 '14 at 19:49
  • 2
    Don't steer away from the standard. Use a randomly generated token, hash it, store the hash in a separate table in the data, give it an expiration date (you don't want a login token that is 245 years old), send the token along with the user ID to the browser as a HMACed cookie. When the user comes back, verify the cookie and look the token up in the database. Easy peasy, lemon squeezy. – Adi Mar 16 '14 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.