BugTraq
Paper: Weaning the Web off of Session Cookies Jan 26 2010 07:05PM
Timothy D. Morgan (tmorgan vsecurity com) (1 replies)
Re: [Webappsec] Paper: Weaning the Web off of Session Cookies Jan 28 2010 10:03PM
James Landis (jcl24 cornell edu) (2 replies)
Re: [Webappsec] Paper: Weaning the Web off of Session Cookies Jan 30 2010 04:07PM
Timothy D. Morgan (tmorgan vsecurity com) (1 replies)
Re: [Webappsec] Paper: Weaning the Web off of Session Cookies Feb 01 2010 08:19PM
Chris Travers (chris metatrontech com)
Re: [Webappsec] Paper: Weaning the Web off of Session Cookies Jan 28 2010 10:51PM
Arian J. Evans (arian evans anachronic com) (1 replies)
Re: [Webappsec] Paper: Weaning the Web off of Session Cookies Jan 30 2010 04:19PM
Timothy D. Morgan (tmorgan vsecurity com) (1 replies)
Re: [Webappsec] Paper: Weaning the Web off of Session Cookies Jan 30 2010 05:31PM
Arian J. Evans (arian evans anachronic com) (1 replies)
Re: [Webappsec] Paper: Weaning the Web off of Session Cookies Jan 30 2010 07:19PM
Timothy D. Morgan (tmorgan vsecurity com)
Arian,

> Regarding SSO - not at all. Not even remotely. It's not about
> "wrappers frameworks put around cookies".

That's exactly what it's about. Cookies are name value pairs sent and
received based on simple rules. Rules that happen to be poorly
standardized with few guarantees. Everything else is what you make of
it: frameworks and protocols that use this primitive as they see fit.

> Spend some time on *.yahoo* and *.google* and their partner sites, and
> look at how they use both auth and personalization cookies (two
> different things).

Whatever google and yahoo and social-networking-site-fad-of-the-month
are doing doesn't really matter to most web developers and
applications. Let them keep their cookies. Most applications will be
better off with a standardized authentication protocol.

> For the former there is no way to solve usefully with Digest without
> implementing some persistent unified tracking mechanism of the likes
> Digest Auth does not provide today, or implementing some massive OoB
> auth-sharing mechanism like SAML, or combining with something like
> SXIP or OpenID. None of these latter give us the changeable
> persistence bits we want and need though, when passing auth around
> multi-domain/host properties.

Digest authentication may lack long-term persistence, I give you that,
but it makes up for it with better defined cross-domain properties.
What I suspect you haven't read up on is the intended use of the
opaque value (and perhaps server-side nonces) in digest
authentication. These can be used to pass information between servers
without any out of band mechanism. Look a lot like cookies, eh?

Also note that I clear all of my cookies whenever I close my browser
and I explicitly reject cross-domain cookies. I'm not alone. Now
where did the utility of cookie persistence go again...? The fact of
the matter is:

persistence + cross-domain = privacy problem

> Sure, it would work fine for isolated financial apps with no
> off-domain links. But that's not the direction the web is moving in.
>
> Auth != Security
>
> Auth != Confidentiality
>
> Auth = Identity
>
> That's the future, like it or not. Cookies are not only "good enough",
> but they have distinct advantages over Digest when it comes to
> verifying and tracking Identity.
>
> But this stuff makes for good thought so keep the ideas rolling,

You speak in grandiose generalities, but have yet to describe any
detail. Care to expand on your argument with something concrete?

tim

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus