6 Jan 2011 16:31
Re: [websec] [kitten] HTTP authentication: the next generation
Ben Laurie <benl <at> google.com>
2011-01-06 15:31:51 GMT
2011-01-06 15:31:51 GMT
On 6 January 2011 01:28, Robert Sayre <sayrer <at> gmail.com> wrote:
> Peter Saint-Andre <stpeter <at> stpeter.im> wrote:These are back on the Web, in case anyone missed them (probably not).
> 2. In 2007, Robert Sayre put together a few slides on the topic:
> http://people.mozilla.com/~sayrer/2007/auth.html
I think the IETF might do better to focus on a smaller problem, at
On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding <fielding <at> 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.
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.
<div> <br><br><div class="gmail_quote">On 6 January 2011 01:28, Robert Sayre <span dir="ltr"><<a href="mailto:sayrer <at> gmail.com">sayrer <at> gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote"> <div class="im">> Peter Saint-Andre <<a href="mailto:stpeter <at> stpeter.im">stpeter <at> stpeter.im</a>> wrote:<br> > 2. In 2007, Robert Sayre put together a few slides on the topic:<br> > <a href="http://people.mozilla.com/~sayrer/2007/auth.html" target="_blank">http://people.mozilla.com/~sayrer/2007/auth.html</a><br><br> </div>These are back on the Web, in case anyone missed them (probably not).<br><div class="im"> <br> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding <<a href="mailto:fielding <at> gbiv.com">fielding <at> gbiv.com</a>> wrote:<br> ><br> > Define them all and let's have a bake-off. It has been 16 years since<br> > HTTP auth was taken out of our hands so that the security experts could<br> > define something perfect. Zero progress so far.<br><br> </div> I think the IETF might do better to focus on a smaller problem, at<br> first. People often use self-signed certificates with HTTP/TLS, even<br> though the first thing their websites ask the user to do is type a<br> username and password into a form. There are some well-understood ways<br> to make this process more secure. Why hasn't the IETF fixed this<br> problem? If this smaller problem has no ready solution, then the<br> larger issue of authentication on the entire Web seems like a tough<br> nut to crack.<br> </blockquote> <div><br></div> <div>Two comments (one really being a response to Roy):</div> <div><br></div> <div>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.</div> <div><br></div> <div>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.</div> <div><br></div> <div>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?</div> <div><br></div> <div>The answer to this problem is hard, since it brings us back to taking the UI out of the sites hands.</div> <div><br></div> <div> </div> <blockquote class="gmail_quote"> It could be that the reasons for this lack of progress are<br> nontechnical. Just throwing that out there.<br> </blockquote> <div><br></div> <div>If you think UI is nontechnical, then I agree.</div> <div><br></div> <div>Cheers,</div> <div><br></div> <div>Ben.</div> <div><br></div> </div> </div>
for the record, I don't think that OAuth itself is a suitable
replacement for HTTP authorisation, but wanted to stir the pot,
especially away from overwrought technical solutions that don't
actually solve anyone's needs.
b.
_______________________________________________
saag mailing list
saag <at> ietf.org
RSS Feed