Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: Check the cookie for changes

by no_slogan (Deacon)
on Mar 26, 2002 at 17:13 UTC ( #154444=note: print w/replies, xml ) Need Help??


in reply to Check the cookie for changes
in thread Web based password management (or how *not* to blame tye)

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.

Replies are listed 'Best First'.
Re: Re: Check the cookie for changes
by drewbie (Chaplain) on Mar 26, 2002 at 17:53 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://154444]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (2)
As of 2019-08-24 20:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?