At 01:44 PM 4/20/00 -0500, Matt Carothers wrote:
>On Thu, 20 Apr 2000, DeWitt Clinton wrote:
>
> > 5) The secure token is associated on the server side (preferably on
> > another tier, such as a database) with the user identification token.
> > Additionally, to support secure session timeouts, the current time
> > must be recorded.
>
>An easy way to implement timeouts is to store a timestamp and a lifetime
>in the secure token itself. For instance, the handler I wrote for our
>web-based administration system at work concatenates the user's username,
>ip address, the current time, and a lifetime then encrypts them with
>Blowfish and sends out the ciphertext in a cookie. Each time a user
>connects, the PerlAuthenHandler decrypts the token and verifies that
>timestamp + lifetime > current time.
>
> > Briefly, the advantage to using cookies is that:
> >
> > a) The user identification token can persist between browser sessions,
> > provided they don't explicitly log out.
>
>Another big win is that the secure token can persist across multiple
>servers. I implemented my cookie-based PerlAuthenHandler because our
>administration system is spread out over four servers. Using Basic
>authentication, users had to re-enter their password for each one. With
>cookies, they can authenticate once on the main server and access the rest
>with the token.
What would prevent the token from being across multiple servers otherwise?
The timestamp not being synchronized amongst them? It seems like that could
be resolved within a reasonable time window to make the token appear OK? Or
are you referring to the persistence of the session info itself?
The nice thing about your encryption is that it makes the cookie into a
kind of pseudo client certificate -- providing information. But at the same
time, I would be concerned that that sort of Encryption overhead (on top of
SSL) seems like it would add load to the server.
How does it work for you in real world use? I suppose it poses an
interesting tradeoff... with that method you don't have to maintain real
session persistence since you have it in your decrypted data? So then you
can avoid an extra IO going to a database or flatfile to retrieve the
session info.
Am I getting this correct?
Later,
Gunther
