mark nottingham

recent entries all entries feed

HTTP Authentication and Forms

Thursday, 26 August 2004

HTTP

It’s no secret that HTTP authentication isn’t used as often as it should be. When I talk to Web developers, there are usually a few reasons for their use of cookies for authentication;

Those last two reasons can be solved by using HTTP Digest Authentication — which has been widely supported for quite some time — but the first two are fair criticisms.

I’ve been frustrated by this for a while, but the other day it occurred to me that we might have an opportunity to fix it in Web Forms, by coming up form controls or widgets to:

If the security-related aspects were handled carefully, I think this has a chance to reduce unnecessary use of cookies, improve security, accessibility and even cacheability, make things easier for automated Web agents, all in one go.

I’ve mentioned it to the WHAT WG. If this seems like a good idea, give them a nudge.


22 Comments

Ian Bicking said:

Another issue I see with HTTP authentication is that it is only sent after receiving a 401 response from the server. That means you can’t have a page that allows anonymous viewers, but is aware of logged-in viewers. That’s embedded in the HTTP spec itself, which makes it hard to fix.

But why Javascript doesn’t have a logout function somewhere, I cannot fathom.

Thursday, August 26 2004 at 3:11 AM

Mark Nottingham said:

Hi Ian,

That’s more or less what I meant by the second bullet. I don’t think a 401 is required to be sent for the client to start sending auth information; witness browsers that “remember” that state between sessions. All that we’re missing is the HTML bits to make it happen.

Thursday, August 26 2004 at 3:19 AM

Marc g said:

This activity has been bugging me for a while. Why are these people revisting html based forms instead of moving to XForms? This seems like duplicate effort and will further hurt adoption of XForms. Now at least Mozilla is heading in the right direction, Opera should follow suit.

Thursday, August 26 2004 at 3:29 AM

Peter Herndon said:

Marc g, Mozilla may be heading in the right direction by implementing XForms, but they’re not stopping their work in WHATWG, either. From what I’ve gotten around to reading about XForms, it looks like a great thing. But I’m not unhappy that we’ll have an implementation of XForms in addition to whatever concrete improvements come out of WHATWG. The only way that this could be bad is if it splits development resources in too many different directions, and hopefully Mozilla’s leadership is taking pains to see that this doesn’t happen too much.

Thursday, August 26 2004 at 3:49 AM

Simon Willison said:

I thought digest authentication was still unusable due to a broken implementation in IE - or has that been fixed now?

Thursday, August 26 2004 at 4:01 AM

Mark Nottingham said:

It’s been working for a couple of years, AFAIK. IIRC Apache’s mod_digest doesn’t work with IE, but mod_auth_digest (which is listed as “experimental” despite having been around for years) does.

Thursday, August 26 2004 at 4:12 AM

Mike D said:

Most excellent suggestion. I think I said the same thing a while ago, but can’t for the life of me find the link right now…

I’ve gone back and forth as to whether extending HTML FORM to put ‘input’ data into the Authentication header is the way to go, or whether to extend HTTP to support server-specified Authentication tokens. With this second approach, name/password would be sent in the POST content body and the response would have a header to set the Authentication token to be re-sent to the server - basically what cookies do.

Thursday, August 26 2004 at 10:00 AM

Mike D said:

Take a look at https://www.w3.org/TR/NOTE-authentform

http://www.mail-archive.com/www-talk@w3.org/msg01380.html

Thursday, August 26 2004 at 10:10 AM

Mike D said:

see also: http://fishbowl.pastiche.org/2003/12/30/saving_http_authentication

Thursday, August 26 2004 at 10:13 AM

Mark Nottingham said:

Aha — so someone has thought of it before! Thanks, Mike.

Another part of why I think this would be so cool is that if HTTP auth was used more, I wouldn’t need separate accounts for Moveable Type, MoinMoin, and every other Web application; authentication would be taken care for them, they’d just need to worry about authorisation.

Thursday, August 26 2004 at 10:56 AM

Bill Seitz said:

Another reason to improve http-auth is because cookie details aren’t standardized, which is a killer for having things like protected feeds that RSS aggregators can handle.

http://webseitz.fluxent.com/wiki/BasicAuthentication

Friday, August 27 2004 at 6:48 AM

anthony baxter said:

Based on a bunch of different things I’ve done recently, the other problem with HTTP Auth is that the implementations are of… variable quality. This, I think, feeds back on itself. Poor HTTP AUTH support means no-one uses it, so the implementations don’t get fixed, &c &c. (For instance, until relatively recently, the Python stdlib’s Digest implementation was horribly, utterly broken).

And that’s not even getting started on horrors like NTLM Auth - anyone using this on a publically accessible web site should be strung up for public mockery.

Friday, August 27 2004 at 10:58 AM

anthony baxter said:

Another point that just occurred to me is that with Firefox’s recent moves to kill annoying popup windows (the recent work to put the Find bar at the bottom of the page, and the “Popups blocked” message at the top), maybe we’ll see Firefox move the HTTP Auth to inside the browsing window. This would certainly make HTTP Auth much less annoying…

Friday, August 27 2004 at 11:00 AM

Mark Nottingham said:

I totally agree that implementation quality of HTTP auth — wherever you look — is really bad.

What scares me about this is that it’s all the more reason for people to roll their own with cookies. If we can’t get it right in the standards and libraries, what chance do they have?

Friday, August 27 2004 at 11:35 AM

Julian Reschke said:

Thanks for the post, Mark.

I think another issue that needs to be solved is how HTTP-based authentication (401) and the new form-based authentication can play together.

Right now, user agents simply ignore the text/html content that a server may be sending with the 401 (assuming it’s just an error page). In the future, user agents should display the page instead of popping up their authentication box if the page content indeed contains a log-on form (maybe the UA should just scan for the new form extension?).

Saturday, August 28 2004 at 4:28 AM

Rich Salz said:

The problem is that you can’t do security and authentication without state. You really don’t want to send your name and password on every transaction. How can that be handled?

Tuesday, August 31 2004 at 9:41 AM

Mark Nottingham said:

HTTP Digest auth doesn’t send your password on every transaction. Yes, it’s derived from your password and a nonce, but it is cryptographically secure (recent development WRT md5 notwithstanding). In this sense, it’s no different than echoing a cookie on every request, or putting an identifier somewhere in the URI, which are the traditional ways to keep such state.

As I understand it, the real limitation of HTTP Digest auth is that it requires that the unhashed password be available at both ends, which make them vulnerable to malicious administrators, those who crack the box, etc. A way of avoiding that while still using HTTP auth would be a real win.

I understand that work is underway on HTTP SASL auth, but I don’t know enough about the details of SASL (and its various permutations) to know if it addresses this. Also, IIRC (and someone I trust has recently confirmed this) the current I-D makes some very nasty assumptions about HTTP connections.

Tuesday, August 31 2004 at 10:09 AM

Mark Nottingham said:

I stand corrected; HTTP Digest auth apparently does not require the cleartext password to be stored on the server. From RFC2617;

“Note that the HTTP server does not actually need to know the user’s cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header may be verified.”

See the spec for an explanation of H(A1).

Monday, September 6 2004 at 5:17 AM

Richard Padley said:

I have logged a bug against mozilla due to the fact that it does not display a message-body for a 401 response unless the user presses the cancel button. Please review this and vote, pressurise etc to get this fixed.

https://bugzilla.mozilla.org/show_bug.cgi?id=271383

Tuesday, December 7 2004 at 2:16 AM

Asbjørn Ulsberg said:

What I see as a challenge, is when a 401 response should and shouldn’t trigger the browser to display the login dialogue. If Content-Length is 0, it makes sense to display it, but should it not be displayed at all if it is larger than 0? I have no idea. What we can do is of course invent a new content type or a new property to signal that “this content contains a login form”. E.g. ‘text/html; auth=yes’.

It seems that some specification work is needed in this area, to somehow consolidate forms and HTTP authenticaiton. Since I found this blog entry through a Google search (for something quite different, but anyway) and it’s 2 years old, things might actually have happened and evolved. Does anyone know?

Monday, October 30 2006 at 1:19 AM

mario said:

Here is a logout solution i found: http://nanodocumet.homedns.org/rest/

Saturday, March 17 2007 at 11:06 AM

sven said:

There exists a hack that uses unobstructive Javascript and AJAX: http://www.peej.co.uk/articles/http-auth-with-html-forms.html

The cool thing is: It works!

Sven

Friday, September 19 2008 at 7:05 AM

about blog home