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

["Arian J. Evans" <arian.evans () anachronic com>]

Meh. Regarding concrete examples - I always like to start with these:

http://*.google.com
http://*.yahoo.com
http://*.adobe.com
http://java.sun.com

No one clears cookies. Personal Web Privacy is a dying agenda. PGP is
dead. The numbers are self evident. Look at the choices, behavior, and
demographics involved with Facebook and MySpace. That is the future.

You mention you clear cookies....and reference that you are not alone.

But you are alone. Especially if you delete RIA cookies. No offense.
That's just a fact.

Do you really block cross-domain RIA cookies? Really?

No one on the planet, even "internet security savvy" people, delete
RIA cookies. It's why SEO and ad network brokering and domainers love
to use them. You know - those people servicing tens of millions of
uniques a month, that drive the internet....

Stats on cookie deletion are widely debated. Anecdotally from family,
from significant ecommerce experience, and from SEO and marketing
folks I know - the percentage of folks who clear cookies on a
meaningful basis is still very low. Take that for what's it's
worth...but it's a pretty well educated guess.

I can find "stats" and "studies" via search engines that argue either
way about cookie retention, so I will agree we don't know for sure how
folks use cookies. But simply looking at artifacts like the number of
users still using ancient browsers and the fact that orgs like Google
drive multi-billion dollar business lines counting on cookie retention
- should give you a clear idea how many people delete cookies.

You are obviously intelligent and put a lot of thought into your
paper, and you made some positive suggestions. I think that is good
and encourage you to continue your work. I'm not debating the
potential inherent value of your ideas either. I once was in favor for
doing exactly this - building strong auth into the protocol, at
protocol and server level, including nonces, etc.

All good ideas, but I believe stillborn at this point. You would get
far more mileage IMO out of promoting "HTTP 2.0" and issuing in a
separate data and control channel for the browser, and then look at
something like this for dynamic auth tokens, combined with data
structure nonces as well. Kill two birds with one stone. Folks that
want strong dynamic auth are probably largely the same folks who want
strong data structures enforced.

But by and large today --

As more and more app development moves to hardware platforms
(iAppleStuffs) and social media aka Ad-metadata networks (Facebook,
Google *.google.com apps, webmail, etc.) cookies are an easy and
transparent way to fly, that work now, all the time, and have clear
business drivers behind them for auth tracking (and working now, all
the time).

Many modern web 2.0 products use cookies for auth = tracking, not auth
= confidentiality.

The majority of internet users use modern apps where auth = "identity
tracking and sharing", and statistics support this.

These same users will readily glue their private, regulated,  banking
apps together with Farmville in some mad web 2.0 gadget-ridden mashup,
that is cross-domain shared and scripted by default. Which is one area
cookies rule.

I'm going to drop out of this thread as we are at a point where we
disagree on premise, and possibly ideology.

Cheerio,

---
Arian Evans
capitalist marksman. eats animals and cookies. And SWF's * access.



On Sat, Jan 30, 2010 at 11:19 AM, Timothy D. Morgan
<tmorgan () vsecurity com> wrote:
> 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/