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: <20100130160744.GE1331@sentinelchicken.org>
Date: Sat, 30 Jan 2010 08:07:44 -0800
From: "Timothy D. Morgan" <tmorgan@...curity.com>
To: James Landis <jcl24@...nell.edu>
Cc: webappsec@...ts.owasp.org, full-disclosure@...ts.grok.org.uk,
	bugtraq@...urityfocus.com
Subject: Re: [Webappsec] Paper: Weaning the Web off of
	Session Cookies

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/