Which is safer?

[rockinaway]

I have a login with a username and password. Which of these is safer?:

 

- Storing the username and password as cookies (the password is hashed and salted before storing it as a cookie)

- Storing just a token as a cookie which is checked against users in the database and retrieves the information

[voip03]

Storing the password in  cookies is like giving house keys to burglars.

- It's NOT secure to store passwords in cookies because they are available as plain text

http://www.cookiecentral.com/c_concept.htm

 

Storing the username  and token is ok, but it is  not 100% secure.

Token -

http://jaspan.com/improved_persistent_login_cookie_best_practice

[rockinaway]

I'm hashing and using a salt before storing the password though?

 

So what would you suggest would be the best way?

 

Because my alternate method was generating a token for a user. This is stored in the database and a cookie is produced too. This cookie is then checked for token value which is checked in the database for the correct user. That is ALL the checking that is done, surely that isn't secure either?

[xyph]

Use a token. Sending a password along with every request is potentially exposing private data on every request. Even if it's generally implausible to crack a properly salted and hashed password, a user's password is generally not yours to expose in any form.

 

If a user chooses to submit a log-in form with their password over an unencrypted connection, that's their choice. Requiring the exposure of that information with every request, in any form, is unnecessary especially when a token that has no link to it is sufficient and requires extremely minimal overhead.

[rockinaway]

Okay so I've take your advice. Here is my setup:

 

- User logs in and a token is created. This is added to the database and a cookie of it is also created. A cookie of their username is created too.

- Both the token and username and checked on each page load to authenticate their use and then information is pulled.

- Each login leads to a new token being generated.

 

Sound okay?

[xyph]

Sounds about right. If you plan to have persistent tokens though (cookies/tokens that persist beyond a single session) I would have the token expire after a certain time and require a new one to be generated. This helps prevent someone who has hijacked the session from taking control until a user manually destroys it by logging out.

 

Generating a new token on log-in will help prevent session fixation, and coupled with generating a new token after x minutes/hours/days will limit the access time when an attacker manages to hijack the session.

 

To explain this better, hijacking a session is when an attacker intercepts the token being send to or from the user. They they create their own cookie that matches the stolen one. When they visit the page, your script assumes that it's still the same user.

 

Some have used band-aid solutions such as making sure the user-agent (browser) or IP address doesn't change between requests. These are unreliable though, as a user-agent is easily spoofed, and legit users may have their IP address change on a per-request basis. I have implemented systems that use the IP check, and allow a user to have 'reduced security' and disable the check if it becomes bothersome.

 

Back to the point, if a hijacked token expires and has to be regenerated, the stolen token becomes useless. If the legit user isn't active and the attacker's request generates a new token, the next time the legit user logs in they will be using a bad token. This will require them to log in again, generating a fresh token and again making the attacker's token useless.

 

You could generate a new token with each request, rather than have it expire. This might be a little extreme though, as an attacker who can intercept the cookies being sent could wait until the user becomes inactive (the token becomes static) before hijacking the session. They would then have control until the user visits the site again, requiring them to log in again and destroying the hijacked token.

 

Hope this helps. I'm quite sure the information I've provided is accurate. I'd be happy to be corrected by any of the experts here though.

[xyph]

OH and to note - There's no point in storing the user name along with the token. Instead, you should store the token in the user table, along with the username. A query like this:

 

(pseudocode)SELECT `username`, `accessLevel` FROM `usertable` WHERE `token` = 'db_sanitize($_COOKIE['tokenName'])'

 

would provide you with the username if you needed to output it at some point.

 

Usernames are generally static, so you COULD store them in a cookie as well. This would take a tiny bit of load off of the MySQL server, but add a few extra bytes to every request. It also causes the data in the cookie to become potentially stale, but for thing like usernames this generally isn't an issue. This is all theoretical though, as any site that would notice the difference between the two methods would have much larger efficiency issues to deal with before something like this would be considered.

[rockinaway]

Very thorough explanation. I'm glad i'm heading in the right direction.

 

You mention expiring and renewing the tokens, however how would you go about this? What check would you carry out? Would you store a time for the token creation and then check against this?

 

Or, alternatively, I check the cookies on every page load so could I just set something that every 30 mins, if the page loads, then the token will be checked and regenerated?

 

As for the username thing - I have two separate cookies; one for username and one for token. I've done it like that just to ensure the correct data is pulled from the database (like an extra verification)

 

Thanks for the help so far!

[xyph]

I'm trying to tell you there's no need for extra verification, unless you're worried about duplicate tokens. If you're worried about duplicate tokens, then you have to take a few steps back and ensure that does't happen. Tokens are useless if there's a chance they can be predicted or that duplicates may exist. It doesn't hurt anything, but it is redundant.

 

I would store the token creation date in the database beside the token. You can either store the time the token will expire and check if NOW is later than that, or store the creation date/time in the database, and check if NOW is later than the creation time+expire time.