On 13 Nov, 2005, at 3:39 pm, Matthew Bevan wrote:

The authentication / authorization systems I wrote while working in
PHP-land involved a unique MD5 hash being sent as the cookie, and local
data (on disk using PHP's sessions or MySQL using home-grown) being
looked up and verified against the MD5, user's IP, browser
identification string (or hash of several different browser-sent
headers - accepted language, etc.).  This was the most secure method I
could think of - taking the information out of the hands of the
browser.

This is definitely good thinking. The more data you put in the hash, the more likely you are to detect possible spoofing. However, I frequently access sites from the local tea shop (they're kind enough to offer free WiFi), my home network, and my work network. I'm not certain everyone wants to re-authenticate each time the browser comes in over a new IP address.

Granted, this is more secure. But I've tried to balance security with convenience.

In my world, the secret token is the only thing being passed around -
it is used as a bySecretToken lookup on a session before other tests
are performed to confirm identity. A la:

Although the identity framework sends the user ID and expiration time, the visitor can't modify them because the cookie is signed -- basically the same thing as handing out only the secret token. I just figure it's a little nicer when the visitor inevitably looks at the cookie to see that it has his ID in there.


--

Jeff Watkins

http://newburyportion.com/


"Just because you have the right to do something, doesn't mean it's the right thing to do."

-- Fred Friendly, former president of CBS News



Reply via email to