Hi Daniel, Thanks for taking the time to read through it.
> This is an area Mozilla has been interested in. You should talk to our > "Mozilla Labs" folks who have been working on Identity in the browser. > They are coming at it from a different angle but there's a lot of > overlap between the problems you and they are trying to solve. > > http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ > http://mozillalabs.com/blog/2009/05/identity-in-the-browser/ Cool, there are some great UI ideas there. I particularly like the examples that eliminate favicons. ;-) I would think that moving toward HTTP authentication schemes, such as digest, would make it much easier to automate a good identity manager. Would you agree? > I have a quibble with your section on HTTPOnly cookies. By mentioning > only IE by name when you follow with "other browsers have been slow to > adopt this feature" people will naturally assume that includes Firefox, > the only other browser with significant marketshare. Firefox has > supported HTTPOnly since 2007. Although perhaps "slow" compared to when > Microsoft invented the feature that's pretty irrelevant for a paper > written three years later when nearly all Firefox users will have > support for it. > > Continuing that quote with "and continue to have difficulties fully > enforcing this rule in light of newer features (such as AJAX > requests/responses)" people will again assume Firefox, when Firefox was > the first to get this right and in fact IE is one of the browsers with > difficulties. You don't have to take my word for it, this is right in > the OWASP chart linked to from your paper and in the "[16]" link from > that chart to one of the OWASP author's blog > http://manicode.blogspot.com/2009/02/firefox-3006-httponly-champion.html I appologize if this comes out wrong. I do realize that Firefox had started implementing this some time back, and I didn't intend to call out Firefox specifically. Firefox clearly has done better than other browsers with newer XHR impacts. I'll update the wording on that. > Your proposal to reinterpret 401 headers is clever and if the IETF HTTP > working group agreed with this interpretation Firefox would follow. The > IETF is currently working on (finishing up) an HTTP revision to clarify > things and you should bring this up with them. In practice, though, I > can't see sites adopting it because of the mass of old browsers who will > behave badly for some time. Your new header proposal would be easier to > get adopted since old browsers are no worse off by ignoring it. I do see your point with adoption. I think a change in newer browsers to 401s won't badly break existing applications using HTTP auth, but new applications won't adopt it until the old browser behavior goes away. Fortunately, the biggest backward compatibility problem is mostly with IE. I think most users of other browsers upgrade pretty quickly to later versions. If Microsoft could be convinced to make this change and push out a service pack for IE7 & IE8 (yes, I know this is a stretch), then perhaps developers would be in the clear in 1-2 years. I have tried to contact the MSRC and submit a newsgroups bug report against IE8 with this information, but I really don't know what the best way is to get a hold of standards-oriented IE developers. Do you know of a good way to contact them? Another thought I had on performing logouts, which is not presented in the paper, is that if the XMLHttpRequest W3C standard is finalized and fully adopted by browsers as is, then one might be able to use JavaScript to clear credentials much in the same way it is used with that cute race condition in Firefox currently. (Recall the reference in my paper how one can initiate an asynchronous call with bogus credentials, then cancel it before the user is prompted.) If users aren't prompted at all when the open() method is provided credentials, then a log out page could just seed it with bogus ones on most (all?) browsers. This could act as a stop-gap measure to provide log out in the short term while 401 behavior is changed. > You must be the Tim who started the "Past proposals for HTTP Auth > Logout" thread and if so you're already involved in the right place for > that. Heh, you did your homework. Yes, I did start that thread. If you read through the discussion , you'll see that some folks champion the idea of an explicit log out, while others say (paraphrasing): "there's nothing stopping browsers from doing this already" I proposed the idea of using the 401 processing change and no one seemed to have a problem with it, but perhaps the thread was dying at that point. Let me also highlight a sentence from RFC 2616 related to the 401 response: "If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information." So I actually am thinking my interpretation is the pretty close. If a user was already logged in and they receive a 401 response, then of course they had "already attempted authentication" on that request. So they "SHOULD be presented with the entity given in the response". Entities of course include, in part, the entity-body. This sentence also implies that if a user messes up the login once, they should stop being prompted, but perhaps that doesn't make sense. Would you be interested in helping me make the case to the HTTP working group? I think many more IETF folks might get involved in the discussion if a representative from a major browser kicked things off. Of course this working group cannot make any real changes to HTTP, they can only clarify things. But maybe more explicit "MAY" and/or "SHOULD" language could make it clear what flexibility user agents have in processing 401s. Thanks for your feedback, tim _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
