Michael C. Neel
neel at mediapulse.com
Mon Nov 24 13:55:41 EST 2003
I'm usally surprised by how many web developers do not fully understand how authencation works over http. First you have to understand it is truly impossible to create a secure connection when you have no control over the client. Worse, the "connection" is not a connection at all, but a series of connection so we have to check the auth for each and every one of them. The best setup you can have is http-auth over an SSL connection. The login info is never written to disk on the client side. The downside is the browser will remember the login info until it is closed. Also, if the connection is not encryped (ssl), then a packet sniffer can get the login info from the heards sent by the client. Sadly there is no way to take login fields on a form and pass the to the client headers as would happen in http-auth. Because the connection is statless, you must then store this login info in cookies, hidden fields, or on the server and pass the client a session key in hidden fields or a cookie. Besides watching with a packet sniffer for headers to get the login info, you can also get the cookie stored on the client system as well. Browsers may write session cookies to disk, even though there is no need. Firebird does this, and even remembers session cookies after it is closed and re-opened (which I assume is a bug, but none the less it does do it). So what can you do if you want the sexy login fields, but still be secure (as is possible)? A lot of things, we may not be able to be 100% secure, but that doesn't mean we have to make it easy. Here is something things to do (many thanks to the Albatross developers for showing me much of this): 1. Build a string or object with as much detail about the client as possible, (IP, user-agent, timestamp). 2. take this string/object gzip it (we have a space limit) 3. Sign this string with MD5 and a key only the server will ever know. 4. base64 encode the signed string to make sure all characters are legit. ...now when we decode the cookie... 1. base64 decode it, and check our md5 sig 2. ungzip the string and parse it back to it's object/string form 3. make sure the IP, user-agent match the current request 4. make sure the timestamp is within our limit for a login Now even if someone gets a copy of the cookie, if they don't know the MD5 key they can't alter it. Most likely their ip and or user-agent won't match either, but if it does the odds are the timeout may have been reached already, esp if it's kept low like 5 or 10 minutes. Mike
|