[Zope] - Secure Server

[Gabe Wachob]

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