Andrew McNaughton wrote:
>
> Gunther Birznieks <[EMAIL PROTECTED]> wrote:
> > [2] Mangled URL Paths
> >
> > Isn't it possible to browse the history on the harddrive... so is this
> > really more secure than non-persistent cookies?
>
> Relying on browser based client side expiration is not a good idea, either for
>cookies or for mangled URL's.
Yes! I hope those of you who attended my short crash course on session
management at the O'Reilly conference took at least this one thing away: if you
need security, you must not ever trust information you get from the client.
Never, ever, ever.
> Either you store information about when the user identifier (cookie or url
>component) was last used on the server, or you put expiration information in the
>cookie content along with a cryptographically secure checksum (as described in the
>modperl book). You must check the expiry time for every authenticated hit.
In my opinion storing anything besides a session key on the client side is
needless extra work. Just give the client a token, in the cookie or in the URL,
and make sure the client sends that token back on every request. Store the
expriration time, the user name, and other information about the session on the
server. Check and update this information on every request. Make the client
reauthenticate after a short period of inactivity (15 minutes, perhaps), and
give the user a way to logout or otherwise destroy their session (in case they
are on a public terminal).
> So what is the security advantage of mangled URLs over cookies for authentication?
I can't think of any security reason, but mangled URLs are more likely to work,
you can bookmark them and get your session back at some other time, etc. There
are huge threads on cookies vs. URLs in the archives.
Cheers,
Jeffrey
