views:

306

answers:

5

I'm creating a login system in PHP, and I want to know how to best protect the user information string in my cookie. I was thinking of encrypting the string with a key somehow? Is this the best way? I'm kinda new to this.

Thanks in advance.

+18  A: 

Don't store sensitive information in cookies. Store a session ID hash to connect the logged in user with their account.

Aaron Harun
And mark the cookie's secure flag if using HTTPS, and HTTPOnly to true.
rFactor
A: 

If you absolutely MUST store information in a cookie instead of the user's session, consider signing it with HMAC. The hash_hmac function is a builtin in modern PHP versions.

If you're storing a user login for a "remember me" feature, store both the user's ID and a hash of information that is only available in your database. For example, hashing together the login name and password and storing that with the user's ID in the cookie is reasonably secure. If the user ever changes their password, all the machines he's logged in to with that method would be invalidated, and there's no way to simply change the ID in the cookie and still get logged in, because the username/password hash won't match.

Charles
How to decrypt the output? Or is it one-way?
DrColossos
HMAC is a hash function, there is no decryption because there is no encryption. It's a tampering detection mechanism. Also, I'm curious as to why I was downvoted.
Charles
The OP is wanting to store data in a cookie and then retrieve it later. A one way hashing function is not the answer. If you wanted to use encryption, you could use one of the encrypting functions, but there are much better ways.
TheLQ
The point of HMAC is to **sign the rest of the data**, to ensure it has not been tampered with. Please at least read the answer before blindly downvoting it.
Charles
Charles the best i could do is to give one Up vote.
andreas
+2  A: 

You should never store secure information in a cookie. Cookies are saved in textformat on the user computer, and there are many reason why you should never stock sensitive informations in them :

  1. Cookies are basically text files, which can be opened by anyone on the computer, with any text editor.
  2. The cookies are stored on the user computer, this mean he have no time limit, no connection limit, no processing limit, so he can try to brute force any data as much as he want without being worried of getting ip banned/kicked...

You should only stock things like a username to remember or a session id.

Dominique
And cookies can be injected and inspected over the wire.
strager
+2  A: 

Aaron Harun has the right answer for you. There's basically no need to encrypt such data as long as you store it in a session, because that data never reaches the client/browser/user, as it is all server-side. When you create a session on PHP, it handles the cookie stuff for you, so you don't have to worry about that. In most cases, there is no need to deal with cookies. In security, dealing with cookies is detrimental.

I've seen some sloppy sites that actually store the username in a hidden field on a form, which allows anybody to simply edit their local copy of that form and take actions as whichever user they like. This seems like an obvious problem, but cookies are no better.

If you truly think it's a good idea to design a homebrew authentication system, you need to design the database first. Don't store plaintext passwords, store a hash instead (like md5, sha-1, etc) and at that point there's no harm in generating a salt for each password (a random string that you append to the user's password before hashing it, and store that salt with the password hash because you'll need it later--this prevents dictionary hash attacks, ie rainbow tables).

andyortlieb
+1 for the extra detail
George Marian
A: 

You get sessions for free! That is data stored server side, automatically handled by PHP/framework-of-your-choice. You just put data into the session, which is associated with a random UID stored in clients' sessions. On the clients' side, this is the session cookie. This ID is automatically generated, you can fine grain the behavior manually.

Data stored client side is never safe, no real encryption available. Sessions you will need anyhow for keep track of logged in users. If you have lots of data, you can use the ID to identify associated data from other datastores (DB, XML etc.)

sibidiba