Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation

[Tim <[e-mail]>]

> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps
> because it is not clear that it is the fix. I speak of RFC 4279, TLS
> pre-shared keys. These could be derived from a hash of the password and the
> site name, for example, and thus provide secure mutual authentication
> despite password reuse.
> 
> 2. I have often heard (though I am not aware of hard evidence for this,
> nevertheless I find it plausible) that one reason no-one has bothered to
> improve HTTP auth is because no-one would use it since site owners want to
> control the user experience around signin. It seems to me, therefore, that
> HTTP is the wrong layer to fix the problem at - it needs to be pushed down
> into HTML or Javascript so that the page can control the look, while
> appropriate HTML elements or JS code can deal with the secure exchange of
> data.

Yes, the user experience piece is definitely the biggest adoption
problem for HTTP auth, IMO.  However, I disagree that HTTP is the
wrong layer.  It has already been shown (by myself and others) that
using HTTP authentication and controlling the user experience can
largely be achieved already.  A few tweaks to browser 401 response
behavior (which doesn't require standards changes) and the ability for
servers to force a log out are all that's left to provide to make
this reliable.

As for RFC 4279, I'm not really familiar with it, but I imagine the
mechansims which allow for user experience customization right now
with HTTP auth could easily be extended to any TLS authentication
mechansim.  The only requirement there would be to add some simple
language allowing for this behavior in [1].  That is, allow
XMLHttpRequest objects to hand the credentials they already accept off
to the TLS layer, either for RFC 4279 or for SRP/TLS.  


> Of course, this still leaves the issue of trusted path: although we can
> provide elements which are safe to use, even when being phished, how does
> the user know those elements are actually being used, rather than simulated
> so as to get hold of the underlying password?
> 
> The answer to this problem is hard, since it brings us back to taking the UI
> out of the sites hands.

Yes, so what I've outlined above and elsewhere is a relatively simple
transition path to allow adoption of better authentication standards
with customizable user interfaces.  But those are problematic by
design.  However, I'd assert that moving web applications off of
cookies to some lower-layer mechanism is going to be a required first
step in order to provide authentication prompts that are part of the
browser, for those who need that security.

tim



1. http://www.w3.org/TR/XMLHttpRequest/