Re: [http-auth] [websec] HTTP authentication: the next generation

Hi Marsh,

> IMHO, authentication just doesn't belong at the HTTP layer.

Hmm, can't necessarily disagree there...  However, I think having it
in the next layer up (POST requests/cookies) is even worse.


> HTTP is inherently bad at being stateful. Stateless interfaces can
> be fantastic, but it doesn't support the "login session" concept
> that most people have in mind when they talk about authentication.

HTTP isn't good at being stateful, but it is.  One could argue that
even just Basic auth alone adds state.  Cookies add state, and we have
connection state.

Ultimately, a non-security form of state management buys a security
protocol nothing.  I think time and again we have found that relying
on insecure underlying state mechanisms in a secure protocol will
bring about insecurities.  Secure protocols need their own state
management independent of the underlying layers.


> Unless you're properly using TLS, you have no reason to believe that
> the byte you just received is from the same party as the previous
> byte you received. So under those circumstances, what exactly are
> you authenticating, and to whom?

Agreed.

> I use a lot of web sites and none of them do authentication via
> HTTP. Every single one of them expects a username/password via
> HTTP(s) POST variables and returns a cookie of varying duration.

Right, and this needs to change, IMHO.  While I'd love to see lots
more adoption of TLS client certificates, I don't think it will ever
completely supplant username/password pairs.  This is because most
people don't understand certificates while everyone understands
usernames and passwords.  Also, there are some real differences in use
cases which will create problems for some sites.


> But what could we possibly do for a stateless, unMACed protocol like
> HTTP, except integrate and bind it better with a lower layer
> providing real integrity?

That's pretty much the solution that Yutaka OIWA and the other Mutual
auth folks have come up with.  You have a protocol over HTTP which
mutually guarantees the server and client have the same password
without leaking the password (this prevents phishing even if users
don't look at the domain name) and this cryptographic process is tied
to the TLS server certificate to prevent MitM.

Could the same security properties be achieved with TLS and say, SRP?
Probably.  The hurdle that SRP has is the user interface. Users and
web developers are accustomed to being able to build their own login
forms.  Now that we (the security community) let them get away with
this foolishness, we can't really take it away from them again. Very
few web developers will give up the ability to build a branded, custom
login form just to use something more secure like SRP over TLS.  So,
how would you go about making it usable with HTML login forms?  I'm
not sure. 

What I *have* investigated in the past is the ability to do HTTP
authentication with custom HTML login forms.  I've found it's not only
possible right now, but the tools to do it (XMLHttpRequest, mostly)
are becoming standardized in a way that makes it well-defined.  So,
there we could have a reasonable tradeoff between usability and
improved security if we pushed for HTML login forms with Mutual auth.


> I think what the world needs are ways for web apps (literally, the
> Ruby code) to easily work with the strongly-authenticated identities
> which are supported at the TLS layer. TLS already supports
> "sessions" and "client authentication", but for whatever reasons
> they're not being utilized. We should make using those facilities as
> easy for web developers as doing cookie-based logins.

Yes, exactly.  So we've already covered how there are many protocols
and protocol frameworks which are secure and integrate well with this,
that, or the other backend system.  Why aren't these adopted already?
It all comes down to how easy it is for web developers to present a
"user friendly" login process.  I think we have enough good crypto out
there.  We should focus on how to make that crypto easier to deploy.

Regards,
tim

Received on Tuesday, 14 December 2010 17:43:18 UTC