Re: Check the cookie for changes

[no_slogan]

When sending any data that is persistent (like a cookie) to the client, you should ALWAYS include a hash (like MD5 or SHA1) of the original value so you can easily see if the cookie value has been modified.

Anyone who modifies the cookie can also recompute the hash value so that it matches. To prevent that, you need to include secret information in the hash itself -- see Digest::HMAC. If you go that route, you can eliminate the need to store session information on the web server at all.

$cookie = join(",", $user_name, $time, $remote_ip);
$cookie .= "," . unpack("H20", hmac_sha1($cookie, $secret));

(I cut the hash down to 80 bits, because that should be enough to prevent a brute-force key search.) Then your only problem is keeping $secret synchronized, if you have a pool of load-balanced servers. Verifying the cookie against both the current secret and the previous secret should give you some leeway so the servers don't all have to be updated at the same instant. It'll also avoid invalidating everybody's current logins when you change the secret.

Update: Yes, that's basically what I meant, drewbie. HMAC is a construction that avoids some possible weaknesses when using a hash as a MAC.

Possible Objection: An attacker who breaks into the web server and learns $secret can log in as anyone.

Response: He can probably forge himself a new Apache::Session, too. Or trojan the login cgi so it saves the passwords in a log file.

[drewbie]

Anyone who modifies the cookie can also recompute the hash value so that it matches. To prevent that, you need to include secret information in the hash itself -- see Digest::HMAC. If you go that route, you can eliminate the need to store session information on the web server at all.

I'm not sure if we're talking about the same thing here or not. The hash I mentioned is a MAC of the cookie value you are sending along w/ a secret string stored on the server. This MAC does prevent the attacker from regenerating the cookie. A good example of this in Apache::TicketTool::make_ticket discussed in the mod_perl book (Writing Apache Modules in Perl and C by Stein & MacEachern) page 317.

So I think we're talking about the same thing. I haven't had time to finish reading RFC 2104 (which Digest::HMAC implements), so I can't be sure. But I know the method I mentioned has been widely discussed as reasonably secure.