I’m beginning to pull together a new client project with a public-facing component, something I haven’t had to build from scratch in a long time. Much of my web consulting over the last several years has involved extensions to existing sites, or building tools for use strictly within a single organization. As such, it’s been a long time since I’ve last had to think about how to handle user authentication in a way that’s both secure and friendly to “walk-in” customers, people who aren’t using the website because they’re literally being paid to do so.1

The last time I built a web-based application with this requirement, I turned to the ubiquitous model of a username / password form, with a prominent “Forgot your password?” link that does all the stuff you’d expect via email. Registration also took the typical tack of sending the new user an email with a URL containing a one-off authentication token. That project’s still out there, getting used every day, and you and I both use web applications using this registration / authentication model every day as well.

The username / password model is so universal and venerable that it lulls us into considering it the way it’s always been done, and simply the only way it shall ever be done forevermore. And yet, I find myself with growing reason to seek alternatives, especially when creating sites meant for the general public’s use.

The project in front of me now will allow folks to book reservations on board my client’s ferry lines. In discussing how this system ought to work, this client described how they wished the site could recognize and assist repeat customers, letting them browse past bookings, and helping them fill out forms when making new reservations. I agreed that these would be nice features, but had only started to mention the utility of stored user accounts when they cut me off. They found the idea immediately distasteful, thinking about how hassled they feel when, using a travel website themselves, the site expects them to remember yet another username / password pair. Beyond that, they feared the additional customer-service overhead this would bring, with their large and active customer base raining down claims of forgotten or broken passwords or otherwise nonfunctional logins.

This isn’t the first time I’ve run into this stance from clients. One I worked with a few years ago already had a website with typical password-based logins, storing the passwords in the site’s database as cleartext. When I started to suggest that there were better ways of storing passwords, this client too cut me off. They were well aware of the dangers inherent in their current pattern, they said, but their clientele forget their passwords so often, and it made them so frustrated with the website, that they’d rather the customers just continue to call on the phone to complain. This would at least allow them to just tell a locked-out customer what their password is, making them immediately feel happier. In my client’s experience, making clientele go through the whole impersonal procedure of begging a robot to email them a link and set up a new (and newly forgettable) password only made many customers more upset, and my client would end up getting an earful about it either way.2

Honestly, I can’t help but agree. While we technically savvy folks may feel comfortable around password-management tools like 1Password, I get the impression that more casual internet users — which is to say, most of them — see passwords as an irritation, which is why so many of them phone it in. Those that do make an effort at better password practices typically forget all the ones they don’t need to type in daily — at, for instance, a ferry service’s website. I myself haven’t the gumption to get on board with 1Password yet, and I definitely fall into the latter camp.

So, tasked with building a new site which even its most frequent public users will only visit a few times per year at most, I feel compelled to see what other experts have been trying. At this point I’d consider implementing bog-standard username / password authentication a failure mode, one I’d choose only if every other path proved even less painful for ordinary users, as well as for my client who hopes to court their business.

After a bit of research, the most promising alternative I’ve seen involves, essentially, letting folks both register and log in by supplying their email address, and that’s all. The system would immediately email them a URL to the site containing a one-time-use authentication token (e.g. http://mysite.example.com/login?token=jEu3838FEheKw387). Visiting this link would expire the token and hand the user a long-lived cookie, letting them continue to return to the site and remain logged in until they manually log out, clear their cookies, or visit the site using a different browser or device.

The surface trade-off of this method, which seems to get independently re-proposed every few years, comes down to freeing users from the irritating security theater of passwords in exchange for adopting the somewhat unusual step of slipping over to their email program every time they wish to login anew. And that’s the leap of faith the site implementor must take, here: the assumption that this context-switch wouldn’t introduce even more frustration than that inherent with passwords. I do find appealing the counterargument that any website which requires an email-based account-validation step already makes their users do this anyway, so why not just simplify everything by extending that one action to cover the entire account creation and authentication process?

I also like the rather more radical idea of offering password-based authentication, but making password use completely optional, though that doesn’t work for every sort of web-based service. Instapaper does this; when creating an account, you can leave your password field blank, and neither it nor any program using the Instapaper API will ever complain about it. A service like Instapaper can arguably get away with this since it doesn’t store anything terribly sensitive about me. A malicious entity using my Instapaper login could, at worst, erase all my articles saved for later reading, or pin up articles I don’t care to read. None of this much affects my identity or my bank account.

However, I have noticed that since its earliest days, this has become an increasingly obscure feature. When I first signed up for Instapaper years ago, its registration form explicitly suggested providing a password only if you felt you had to, and API-using clients would suggest that you probably didn’t have a password. But all these messages have since phased themselves out, suggesting to me that Instapaper found it less troublesome to just appear to offer totally ordinary username / password authentication.

And I suppose that that illustrates my main concern over any new authentication style. Username / password is irritating and abused, but it’s familiar, even to casual users. Introducing an unfamiliar technique for something so common as logging in to a website is not a thing a wise hacker implements lightly. So far the only website I’ve found that implements email-token logins involved discussion of a particular Linux distribution, which fails to serve as an endorsement for something that would appeal to an everyday web user.

That said, it’s not exactly easy to google for websites based on their login schemes, and I may very well be overlooking examples of friendly, public-facing websites that have successfully escaped the misery of passwords. I would quite welcome word of any.