Scott Robertson wrote:
On Mon, 25 Jan 1999, Christopher G. Petrilli wrote:
Based on real-world benchmarks, SSL generally has a order of magnitude impact (sometimes more) on performance... the key negotiation is a huge CPU burdon, and must be perfomred with the start of each SSL session (which under HTTP/1.0 is every HTTP query)... what I've recommended to a lot of people doing "high performance" servers is to use SSL to gather UID/password, then issue a "ticket" (aka cookie) that is valid, and then let the cookie be passed around. While this isn't 100%, and does allow for certain types of replay/mim vectors, it does provide a good bit more real world security than passing uids in the clear.
Sounds good, do you think it would be worth it to hash the ip address into the ticket so that you can almsot gauranty that the owner of the cookie is the same person the cookie was issued to?
I set this as a cookie with this value on the user's browser each time they visit a page requiring authentication (after they've logged in of course): userip/userid/activitytimestamp/logintmestamp/MD5(userip/userid/activitytimestamp/logintimestamp/serversecret) The activitytimestamp gets changed every time there is a succesful access. Thus, a "timeout" is established (the amount of time the activitytimestamp is set ahead from now is that timeout period). Prevents replay attacks after the timeout period, and is only valid from a particular IP. Now, there is an mitm and ip-spoofing-based attack, but the system is relatively fast. The serversecret part of the hash is known only to the server, and is used as a shortcut so that the server doesn't have to check the user's password for each hit. When the logintimestamp becomes a certain amount of time old , you then check to see if the user's authentication information has changed (without actually retrieving that authentication information). If that authentication information has changed, then you force the user to reauthenticate (and then you update logintimestamp). This lets you efficiently (ie only periodic connection to an authentication database -- and even then only to retrieve "last modified" information), and fairly surely authenticate who is using the session. -Gabe