Mailing List Archive: Full Disclosure: Full-Disclosure

Paper: Weaning the Web off of Session Cookies

Full Disclosure full-disclosure RSS feed

Index | Next | Previous | View Threaded

tmorgan at vsecurity

Jan 26, 2010, 11:05 AM

Post #1 of 10 (1366 views)
Permalink

Paper: Weaning the Web off of Session Cookies

Hello,

I've just posted a new paper some of you may be interested in:
http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

While it's primarily an argument for fixing HTTP authentication, it
does contain information on a few weaknesses common in browsers,
including password manager issues and user interface vulnerabilities.

Feedback is more than welcome.

Enjoy,
tim

Abstract
========
In this paper, we compare the security weaknesses and usability
limitations of both cookie-based session management and HTTP digest
authentication; demonstrating how digest authentication is clearly the
more secure system in practice. We propose several small changes in
browser behavior and HTTP standards that will make HTTP authentication
schemes, such as digest authentication, a viable option in future
application development.

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

jcl24 at cornell

Jan 28, 2010, 2:03 PM

Post #2 of 10 (1293 views)
Permalink

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

Tim,
Great writeup of the state of the union for Web-based authentication methods.

As you mention, your paper is primarily an argument for fixing HTTP
auth. That might make a better title for it, in fact, since that does
seem to be the primary thrust of the arguments presented. Or at least,
"If We Wean the Web Off of Session Cookies, This Is Some of What We'd
Have to do". I wasn't convinced at all that Weaning the Web Off of
Session Cookies was the logical conclusion of the data you presented.

To solve problems with forms-based auth + session tokens, we only have
to fix some things in Web app frameworks, many of which have already
been fixed in major platforms. Predictable session identifiers, for
instance, pretty much died out years ago. To migrate to HTTP Digest
Auth, not only would we have to fix a few things in Web app
frameworks, we'd have to refactor a massive amount of custom code AND
convince all major browser vendors all to do the same right things and
THEN force everyone to update their UA to the latest version.

I'm not sure you've identified the path of least resistance! :)

-j

On Tue, Jan 26, 2010 at 11:05 AM, Timothy D. Morgan
<tmorgan [at] vsecurity> wrote:
>
> Hello,
>
> I've just posted a new paper some of you may be interested in:
> http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
>
> While it's primarily an argument for fixing HTTP authentication, it
> does contain information on a few weaknesses common in browsers,
> including password manager issues and user interface vulnerabilities.
>
> Feedback is more than welcome.
>
> Enjoy,
> tim
>
>
> Abstract
> ========
> In this paper, we compare the security weaknesses and usability
> limitations of both cookie-based session management and HTTP digest
> authentication; demonstrating how digest authentication is clearly the
> more secure system in practice. We propose several small changes in
> browser behavior and HTTP standards that will make HTTP authentication
> schemes, such as digest authentication, a viable option in future
> application development.
> _______________________________________________
> Webappsec mailing list
> Webappsec [at] lists
> https://lists.owasp.org/mailman/listinfo/webappsec
>

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

arian.evans at anachronic

Jan 28, 2010, 2:51 PM

Post #3 of 10 (1302 views)
Permalink

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

Good points James. I read this paper a few times to make sure I got
the point, and it's a cute idea but I just don't see it happening.

For multi-node, multi-app, websites sharing auth/state/preferences
across multiple web assets (physical servers and logical "websites")
this is pretty much a non-starter. Cookies rule here. For a dozen
different reasons that I can think of.

Always good to try and raise the bar, but the world has voted cookies
(thanks Lou!) and I think they are here to stay for at least the next
decade.

Oh, yeah, and marketing rules the world, and web sales and marketing
(and Google) LOVE cookies. So that is what it is and I really don't
see that changing until they can inject a tracking device into your
body.

---
Arian Evans
capitalist marksman. eats animals.

On Thu, Jan 28, 2010 at 2:03 PM, James Landis <jcl24 [at] cornell> wrote:
> Tim,
> Great writeup of the state of the union for Web-based authentication methods.
>
> As you mention, your paper is primarily an argument for fixing HTTP
> auth. That might make a better title for it, in fact, since that does
> seem to be the primary thrust of the arguments presented. Or at least,
> "If We Wean the Web Off of Session Cookies, This Is Some of What We'd
> Have to do". I wasn't convinced at all that Weaning the Web Off of
> Session Cookies was the logical conclusion of the data you presented.
>
> To solve problems with forms-based auth + session tokens, we only have
> to fix some things in Web app frameworks, many of which have already
> been fixed in major platforms. Predictable session identifiers, for
> instance, pretty much died out years ago. To migrate to HTTP Digest
> Auth, not only would we have to fix a few things in Web app
> frameworks, we'd have to refactor a massive amount of custom code AND
> convince all major browser vendors all to do the same right things and
> THEN force everyone to update their UA to the latest version.
>
> I'm not sure you've identified the path of least resistance! :)
>
> -j
>
> On Tue, Jan 26, 2010 at 11:05 AM, Timothy D. Morgan
> <tmorgan [at] vsecurity> wrote:
>>
>> Hello,
>>
>> I've just posted a new paper some of you may be interested in:
>> http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
>>
>> While it's primarily an argument for fixing HTTP authentication, it
>> does contain information on a few weaknesses common in browsers,
>> including password manager issues and user interface vulnerabilities.
>>
>> Feedback is more than welcome.
>>
>> Enjoy,
>> tim
>>
>>
>> Abstract
>> ========
>> In this paper, we compare the security weaknesses and usability
>> limitations of both cookie-based session management and HTTP digest
>> authentication; demonstrating how digest authentication is clearly the
>> more secure system in practice. We propose several small changes in
>> browser behavior and HTTP standards that will make HTTP authentication
>> schemes, such as digest authentication, a viable option in future
>> application development.
>> _______________________________________________
>> Webappsec mailing list
>> Webappsec [at] lists
>> https://lists.owasp.org/mailman/listinfo/webappsec
>>
> _______________________________________________
> Webappsec mailing list
> Webappsec [at] lists
> https://lists.owasp.org/mailman/listinfo/webappsec
>

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

tmorgan at vsecurity

Jan 30, 2010, 8:07 AM

Post #4 of 10 (1250 views)
Permalink

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

Hi James,

> Great writeup of the state of the union for Web-based authentication
> methods.

Thanks. It is far from complete in that sense, but I hope it
illustrates the frog-in-the-frying-pan state we are in with session
cookies.

> As you mention, your paper is primarily an argument for fixing HTTP
> auth. That might make a better title for it, in fact, since that does
> seem to be the primary thrust of the arguments presented. Or at least,
> "If We Wean the Web Off of Session Cookies, This Is Some of What We'd
> Have to do". I wasn't convinced at all that Weaning the Web Off of
> Session Cookies was the logical conclusion of the data you presented.

I had a hard time conveying what I wanted to with the title. As far
as being convincing, well, I guess it's a matter of perspective.

> To solve problems with forms-based auth + session tokens, we only have
> to fix some things in Web app frameworks, many of which have already
> been fixed in major platforms. Predictable session identifiers, for
> instance, pretty much died out years ago.

Yes, but app frameworks come and go. I think session cookies will
continue to be a "maintenance" problem with respect to security. In
addition, cookies are a pretty limited mechanism for providing more
secure protocols.

For instance, if I wanted to implement something like SRP
<http://srp.stanford.edu/>, I can't simply treat the browser as a dumb
repeater of cookie values. It needs to interact in a
protocol-specific way that is much better suited to use in HTTP auth.
A great example of this is Mutual authentication
<https://www.rcis.aist.go.jp/special/MutualAuth/>, which implements
SRP and can provide protection from phishing attacks.

> To migrate to HTTP Digest
> Auth, not only would we have to fix a few things in Web app
> frameworks, we'd have to refactor a massive amount of custom code AND
> convince all major browser vendors all to do the same right things and
> THEN force everyone to update their UA to the latest version.
>
> I'm not sure you've identified the path of least resistance! :)

It may not be a simple fix, but the first steps shouldn't have much
resistance. While digest authentication isn't the best password
protocol out there, it's almost usable right now and provides tangible
security benefits for those adventurous developers who are willing to
work around browser limitations. With some very small changes in
browser behavior, form-based HTTP authentication becomes truly
possible without ugly hacks. From there, I think it can gain some
real traction under it's own merits.

Of course some apps will always use cookies for flexibility or
backward compatibility, but I don't see cookies *advancing* the safety
of web authenticaiton. HTTP authentication schemes can do that.

Thanks for the feedback,
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/

tmorgan at vsecurity

Jan 30, 2010, 8:19 AM

Post #5 of 10 (1242 views)
Permalink

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

Hi Arian,

> Good points James. I read this paper a few times to make sure I got
> the point, and it's a cute idea but I just don't see it happening.

Pessimism is understandable; I don't fault you for that.

> For multi-node, multi-app, websites sharing auth/state/preferences
> across multiple web assets (physical servers and logical "websites")
> this is pretty much a non-starter. Cookies rule here. For a dozen
> different reasons that I can think of.

Well, I'm sure you read this, but digest auth can do SSO to, arguably
better. Whatever wrappers frameworks put around cookies, which are a
very simple primitive, can be wrapped around digest auth too.

> Always good to try and raise the bar, but the world has voted cookies
> (thanks Lou!) and I think they are here to stay for at least the next
> decade.

Definitely, they aren't going away, but we should start phasing them
out of authentication. What the replacement is may be up in the air,
but the bottom line is: Cookies were a terrible idea for
authentication when they were first introduced and they are still a
bad idea. We've been hit over the head with this for years.

> Oh, yeah, and marketing rules the world, and web sales and marketing
> (and Google) LOVE cookies. So that is what it is and I really don't
> see that changing until they can inject a tracking device into your
> body.

As the paper points out, these business drivers act against making
cookie primitives more usable for session management.

Thanks for taking the time to read it,
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/

arian.evans at anachronic

Jan 30, 2010, 9:31 AM

Post #6 of 10 (1209 views)
Permalink

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

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

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).

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.

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,

---
Arian Evans
capitalist marksman. eats animals and cookies.

On Sat, Jan 30, 2010 at 8:19 AM, Timothy D. Morgan
<tmorgan [at] vsecurity> wrote:
>
> Hi Arian,
>
>> Good points James. I read this paper a few times to make sure I got
>> the point, and it's a cute idea but I just don't see it happening.
>
> Pessimism is understandable; I don't fault you for that.
>
>> For multi-node, multi-app, websites sharing auth/state/preferences
>> across multiple web assets (physical servers and logical "websites")
>> this is pretty much a non-starter. Cookies rule here. For a dozen
>> different reasons that I can think of.
>
> Well, I'm sure you read this, but digest auth can do SSO to, arguably
> better. Whatever wrappers frameworks put around cookies, which are a
> very simple primitive, can be wrapped around digest auth too.
>
>> Always good to try and raise the bar, but the world has voted cookies
>> (thanks Lou!) and I think they are here to stay for at least the next
>> decade.
>
> Definitely, they aren't going away, but we should start phasing them
> out of authentication. What the replacement is may be up in the air,
> but the bottom line is: Cookies were a terrible idea for
> authentication when they were first introduced and they are still a
> bad idea. We've been hit over the head with this for years.
>
>> Oh, yeah, and marketing rules the world, and web sales and marketing
>> (and Google) LOVE cookies. So that is what it is and I really don't
>> see that changing until they can inject a tracking device into your
>> body.
>
> As the paper points out, these business drivers act against making
> cookie primitives more usable for session management.
>
> Thanks for taking the time to read it,
> 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/

tmorgan at vsecurity

Jan 30, 2010, 11:19 AM

Post #7 of 10 (1234 views)
Permalink

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

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/

arian.evans at anachronic

Jan 30, 2010, 12:40 PM

Post #8 of 10 (1206 views)
Permalink

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

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 [at] vsecurity> 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/

chris at metatrontech

Feb 1, 2010, 12:19 PM

Post #9 of 10 (1082 views)
Permalink

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

Hi all;

Just backing up Tim here a bit.

In LedgerSMB 1.3, we decided to go to HTTP auth because of some
changes in the security architecture of the software. After looking
at alternatives, we concluded that http auth was likely to be the way
to go long-run. There are some constraints which preclude the use of
Digest authentication (negotiated and basic work OK, but the latter
really requires SSL).

In general the issues came down to:

1) We do pass-through authentication, and both authentication and
permissions enforcement occurs on the database-level.
2) To do this effectively, we would have to either store the database
passwords somewhere accessible to the web server (opening up possible
attacks) or we would have to pass it back using some sort of secure,
but reversible encryption scheme. Since the key would have to be
accessible on the server, this didn't seem as secure to us as just
requiring a usable auth token to be passed to the web server via http
auth.

There are substantial hurdles to overcome to make this work. However,
moving to an HTTP auth framework means that a number of really
powerful tools are gained. While it isn't standard yet, I hope the
industry moves in that direction.

I do think we need some sort of HTTP status or other header
information that would tell a browser to clear the auth cache and not
try again.

Best Wishes,
Chris Travers

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

tmorgan at vsecurity

Feb 5, 2010, 8:06 AM

Post #10 of 10 (961 views)
Permalink

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

Arian,

Sorry for the slow reply. I'm overseas right now and it's tough to
keep up with email.

I think this thread might be about dead, but I will respond to a few
comments:

> 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.

Far too often security initiatives fail to gain any momentum because
they bite of far more than they can chew. I'd love to redesign digest
authentication, for instance, or push for good browser support of some
truly safe HTTP authentication protocols, but that would be much more
likely to fail. I see this as a relatively easy fix to open up a new
option in web app development.

> 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.

I never said cookies should go away. I merely want cookies to stop
being used for managing authenticated sessions in most applications.
Some applications may still require that flexibility, however, and for
those they can be more carefully audited.

> 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.

Well, sure, they do currently rule. There's no reason HTTP
authentication can't be used to authenticate a cross-origin unified
identity.

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

I'm fine to agree on disagreeing as well.

Cheers,
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/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads