full-disclosure - Re: [Webappsec] Paper: Weaning the Web off of Session Cookies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100130191958.GK1331@sentinelchicken.org>
Date: Sat, 30 Jan 2010 11:19:58 -0800
From: "Timothy D. Morgan" <tmorgan@...curity.com>
To: "Arian J. Evans" <arian.evans@...chronic.com>
Cc: Full-Disclosure <full-disclosure@...ts.grok.org.uk>,
	bugtraq@...urityfocus.com, websecurity@...appsec.org
Subject: Re: [Webappsec] Paper: Weaning the Web off of
	Session Cookies

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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/