Had a quick question. I have never messed with cookies before, but I know how they work. I am working on a user login and want to be able to use a remember me option, using cookies to do so.

I basically have it setup so I save the users id, username, password (salted and hashed), a unique token value and expiration in a cookie, and it is also saved in a database for lookup.

My question, is there any problem with storing a username and password in a cookie if the password is hashed and salted? The way I process the login, there is no sending of this value raw to the login methods. If so, the salted and hashed password in the cookie with be salted and hashed returning a different value.

Sorry for noobness with cookies, but never used this feature before.

Oh yea, also, when checking the cookies with what was entered in the database upon setting the cookie, I do it strictly. Every single piece of data must match or I remove the token information. I am also doing other small things such as checking the user agent and am using Kohana 2.4 session/cookie handling. Thanks.

You should avoid putting the password into plain sight, especially when it's ultimately unnecessary - leave any critical information such as that (hashed or otherwise) stored behind a lock and key, and only use it when you need to.

It should be more than sufficient to store their user id, a session id (the unique token) and for a little extra security you can hash the user agent and store that too. In my own authentication script I hashed the ua with a random salt stored in the authentication table (similar to how the password was hashed) and concatenated the three values into a single string which was stored in the cookie.

The method that checked the authentication knew how to read the string and could split it up into its parts (don't use something like a seperator, if you're using a hash you should know the length of each value) and then run them against the data stored in the session table. This is just one way, there's a lot of others that work quite well. Just avoid putting the password out there into the world.

Ok I will look into it. I do also hash the user agent, I really didn't want anything in the cookie viewable but some information would be obvious. A user can easily find any users username and most of the time, their user id. I wasn't sure about the password but I don't think anyone could ever decrypt it since it's salted and ran through sha1. I will try to find a way around using the password in the cookie. Thanks.

Just don't use it at all. You don't need it in there - and chances are 99% of the script kiddiez out there who will attempt to break into your system won't have a clue what to do with a salted sha1, but why open the door for them? Lock the door, and then still hide your ice cream in the back of the freezer.

When validating users, use their unique database ID and a login key that you generate at login. This is how the login I wrote for a band worked.

1. User enters email and password
2. If they match, the script generates a login key (3/IGW4/?#6HW4 for example) and puts that and the users ID in seperate cookies. It also inserts these rows into the login table with the time.
3. Future pages validate based off of those two pieces of information in the login table.
4. After a certain amount of time of inactivity (we monitored every move made on the site) or if another log in takes place, the information in deactivated and kept for records.

This allowed us to see when users logged in and to log them out if we wanted to. It also provided security since the keys expired after a few minutes of inactivity, so having the login cookies would only work for a short time.

__________________

Thanks guys, this should get me finishing this up.