What's Wrong With It

HTTP authentication (which I'll refer to as "httpauth") is useful when you want to quickly control access to something; you only need a few lines in your web server's configuration file to get it set up.

Unfortunately it's not good for much more than that, due to the terrible interface that every browser I've ever used has somehow settled upon. This interface presents three major problems:

First, most sites want to give the user the option to log in even if the page they're looking at does not strictly require it. Httpauth supports this, but browsers don't.

Worse, browsers throw up an authentication dialog as soon as they encounter a 401 Unauthorized response, without any context. If the user does not have an account, or has forgotten their password, their only option is to "Cancel" the dialog (to which the site's response is usually a frightening, uncustomized Unauthorized page).

Finally, once the user is logged in there's no obvious way to log out. Closing your browser will generally log you out, but this is hardly obvious.* This is easy to implement on the browser side - simply stop sending authentication data to a site after the button is pressed.

(I'm not the first to observe these problems (1, 2, 3). Bookmooch seems to have worked around them, but it's still far from perfect despite their efforts.)

Why It's Worth Fixing

But why bother? These days we use HTML forms and cookies for authentication on anything that matters, and it seems to work. Isn't httpauth an outdated technique, incapable of providing the rich authentication experience that today's users demand?

Well, no. Httpauth is perfectly capable; in fact it is preferable to cookie-based authentication in several ways:

• it can be more secure than HTML forms when SSL is not available. Digest authentication only sends hashed passwords. Servers can trade system resources for immunity to replay and session hijacking attacks (see section 4.5 of RFC2617).
• it can be completely stateless; multiple servers running the same site don't need to share a session store when Basic authentication is used.
• it simplifies caching. Responses to unauthenticated requests are cached normally, responses to authenticated requests go uncached.
• it works well with AJAX and with automated clients. Do you really need separate authentication mechanisms for your front-end and for your API?

As a bit of a purist, I think the best part is that your authentication layer can be completely separated from the rest of your application. You shouldn't need to clutter your interface or your code with authentication trivia. It's a classic example of code reuse; we're extracting an incredibly common pattern and moving it so that we don't need to recreate it every time we use it.

But there's not much point if we have to confuse and scare users to get these things. What to do about that?

How to Fix It

The slide-in toolbar (apparently called an infobar) that browsers have adopted provides a solution. I've made some mockups of what it could look like (please excuse the programmer art).

The browser would notify the user that they can log in without interrupting their browsing:

The bar sits there quietly waiting for them to log in. If the user requests something private, then the server sends back a 401 Unauthorized. This would need to be something friendly that allows the user to create an account, reset a password, etc.

When the user is logged in they would see something like this:

I'm sure these can be improved upon. Some kind of immediate user feedback is still required for requests that happen in the background (i.e. AJAX). Browser real estate is precious and I wouldn't want to look at that on every site that I'm ever logged into.

Conclusions

Writing the authentication infrastructure for a web application is not difficult, but it's still more work than letting some standard component do the work. The unhelpful UI the standard component has been given is the only reason we can't do that now.

My proposal is very similar to at least one that has been suggested on Bugzilla; the long time that one has been ignored is not promising. I've looked into implementing this myself, but - to be frank - Mozilla's codebase terrifies me (please contact me if you have any guidance).

Coordinating big chunks of code is tricky. Coordinating big groups of people working on big chunks of code is trickier, but if we can't get something as obviously broken as this fixed, then I fear for the future of the web.

*: Some (most? all?) browsers forget credentials for a site if the site sends them a 401 Unauthorized. Websites could provide a "log out" link that always 401s, but this is awkward.

After watching some Skinny Puppy videos that used VHS artifacts to great effect I wondered how long it would be until we saw digital compression artifacts used similarly; I guess that time has arrived.

I must admit that I expected it to be used spookily, in the same way that (to coin a term) VHSpunk was. Cool effect, though.

A David Duke article posted to the openmoko-announce mailing list? I hope sean@openmoko.com has some bizarre virus.

Update: It was spam with a forged From address. Email is a broken, broken set of technical and social protocols.

Ran across a link to Last Week in HTML5 and spent the rest of the day catching up with the drama surrounding HTML5. I sympathise deeply with Mr last week.

Giovanni Campagna has summed up something I've been thinking for a while:

Actually the web, is already divided in two big groups:

• Web of data
• Web of interaction

Web of data means all the page whose primary objective is to provide some information, either user-readable or machine-readable to the users, while web of interaction include web application, whose primary purpose is to provide additional services to the users. These two groups have very different requirements (GMail doesn't need RDFa in application code, while Wikipedia doesn't need a progress element), so specific markup languages may suit better the web site.

It's very strange to try to write application interfaces and documents in the same language. Too bad XHTML2 was strangled in infancy.

It seems that Ruby is getting a reputation for having an argumentative community.

It's sad, the lack of standard Internet nastiness is exactly what attracted me to the language in the first place. Unfortunately Rails culture is not Ruby culture, and Rails still gets all the attention.

We need more _why and less Zed.

Thank god, that circus to the south is finally over. I'm so sick of the shallow idiocy that is American politics.

Only 2 more years until we get to do it all over again. Maybe I need to start moving to non-English media.

I'm willing to accept that XMPP ESessions are dead; as far as I can tell there's no interest in other implementations, and some form of client-to-client TLS is looking promising (though I'm a bit worried about requiring Jingle).

Implementing ESessions hasn't been a total loss, though. I think we've built a good casual crypto UI model for Gajim, and I would like to see something similar to it in other clients.

Here's an overview. Please ignore the specific text used in the screenshots, I know it sucks. Suggestions would be appreciated.

UI Flow

If the other client supports end-to-end encryption, an encrypted session is negotiated in the background as soon as you start typing.

The shield icon is from Tango. It's not a great metaphor, but I think that it's better than a padlock. The question mark is our own addition. We use a different icon when the contact has been authenticated.

When you click the shield icon, you get this dialog. The idea is to provide the basic information about the session; something like Firefox's Page Info Security dialog. If we were using public keys for authentication, that info would appear here.

When you click "Verify" on the session info dialog, you get this dialog. Clicking "Yes" marks the session (and all future sessions using the same shared retained secret) as authenticated. Clicking "No" just closes the dialog.

I think the core idea is to encrypt by default without requiring the user's intervention (even for authentication), but to make it clear what that means and make it easy to authenticate at any time.

(inspired by the big thread about XMPP end-to-end security over at security@xmpp.org)

Authentication sucks. Without it, crypto is automatic and decentralized, but insecure; doing it introduces a dependency on human intervention or a trusted third party.

I don't like trusting "authoritative" third parties, so I'm most interested in making the human intervention required as simple as possible.

Aiming for an authentication system that Aunt Tillie will use is unrealistic; there's no reason for her to care.

But we should aim higher than Uncle Peter, who always checks SSH fingerprints and is willing to do whatever he needs to when privacy is important.

A better target is Cousin Dave, who works in IT or took a CompSci course at business school. He doesn't know the difference between Diffie-Hellman and Blum Blum Shub, but he's aware of crypto, he's competent, and he's willing to expend minimal_amount_of_effort for privacy.

This is not to say that Uncle Peter's use cases should be neglected, just that a system doesn't need to be 100% usable by everybody to be better than what we've got.

Support for short authentication strings lowers the barrier to entry nicely, without making any significant compromises.