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

On 6 January 2011 01:28, Robert Sayre <sayrer@gmail.com> wrote:

> > Peter Saint-Andre <stpeter@stpeter.im> wrote:
> > 2. In 2007, Robert Sayre put together a few slides on the topic:
> > http://people.mozilla.com/~sayrer/2007/auth.html
>
> These are back on the Web, in case anyone missed them (probably not).
>
> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding <fielding@gbiv.com>
> wrote:
> >
> > Define them all and let's have a bake-off.  It has been 16 years since
> > HTTP auth was taken out of our hands so that the security experts could
> > define something perfect.  Zero progress so far.
>
> I think the IETF might do better to focus on a smaller problem, at
> first. People often use self-signed certificates with HTTP/TLS, even
> though the first thing their websites ask the user to do is type a
> username and password into a form. There are some well-understood ways
> to make this process more secure. Why hasn't the IETF fixed this
> problem? If this smaller problem has no ready solution, then the
> larger issue of authentication on the entire Web seems like a tough
> nut to crack.
>

Two comments (one really being a response to Roy):

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.

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.



> It could be that the reasons for this lack of progress are
> nontechnical. Just throwing that out there.
>

If you think UI is nontechnical, then I agree.

Cheers,

Ben.