Secure Cookies?

Question

I am slowly moving my (unreleased) CMS from $_SESSION to $_COOKIE. Content on the internet seems to be biased more towards $_SESSION (I assume because ease of use). I am looking for security tips on saving cookies. Currently, I am storing (somewhat similar WordPress) a cookie in the format:

'logged_in_%hash_key%' => "username | %hash_password%"

Where my %hash_key% is md5(MYSALT."something".UNIQUE_KEY) and UNIQUE_KEY is regenerated (if the user chooses) after each login to lock out other computers that might have a cookie stored. It is a random 6-character string.

%hash_password% is similarly generated with Salt and random key (hashed).

I must know the key of the $_COOKIE (obviously), then I split the string by "|" and look at the username and password. If something doesn't match, I destroy the cookies.

My question is: do you have any other tips on storing cookies in a secure format, or is this good?

I also generate a nonce for each requested action. For example, I create a nonce for 'delete' and I expect to get that nonce back in my $_REQUEST. I don't log the user out if I get an incorrect response, but I don't do anything.

As meagar pointed out, I know COOKIES are inherently unsafe, I am still trying to do my best to make it all secure.

Answer 1

If the communication between server and client is a real communication it gets hard for the hacker. The server send a question to the client - lets say he send a known html ID. The client answer with the content of the name attribute of that element. Of course the server must be able to verify the answer. Be creative.

As long as the client is online you don't need the cookie any more, there are other ways. But if he leave, the script could send an ajax request to the server on before unload to get a new cookie/question. (onbeforeunload now available on safari too)

Offer a log out button.

Let the sever send a new question after each external link automatically.

Uglify the client script to a one line cryptic mishmash to hide the answer algorithm.

And don't forget the bunch of other risks and properties.

Answer 2

I saw from one of your comments that you wanted a login with Remember Me. A simple solution is just to increase the expiration time of $_SESSION (or implement your own session algorithm). However, that is generally considered unfavorable. This is a great article on how you would create a secure remember me:

http://jaspan.com/improved_persistent_login_cookie_best_practice

The basic idea is:

Cookies:

• Username/Email/etc
• Token
• Series

The token is changed every time the user loads a page. However, the series remains the same for the entire duration of the remember me period. You would keep a table of the series and the token in a database (possibly MySQL).

I'm not very good at explaining it, so I highly encourage you to read the article.

Answer 3

I'm all for using $_COOKIE over $_SESSION, because I believe it's more professional in regards to data privacy. But authorization is the one use case where it's inappropriate. Keep using $_SESSION.

The session fixation problem is avoided with a few simple steps. Most importantly ensure that session_start() doesn't blindly accept session ids. Ensure that the session was created by the server by giving it a default token:

if (empty($_SESSION["ok"])) {   // would be empty for injected ids
    session_regenerate_id();
    $_SESSION['ok'] = 1;
}

As second measure use a fingerprint. It's best to store the original request IP. But only verify e.g. the first 16 bits to work around proxy issues. Very commonly the HTTP_USER_AGENT is used as fingerprint. And you should additionally give each session a pre-defined expiry time.

Answer 4

"Secure cookies" is an oxymoron. Stick with server-side sessions, this is exactly what they're suited to. What is your reason for leaving them in the first place?