Forget Passwords!
This is a case study of how I solved a business-slash-UX problem that had been nagging at me for years, by ultimately rolling up my sleeves and writing the code myself.
Preface: If any of this or any other case study reads like something I can help you and your team with, do note that I am available for hire! Just drop me a line.
The Web is the principal vehicle by which I deliver my work product to clients. I create an extranet (that is, a private intranet on the public internet) for each client at the beginning of—or even before—each engagement, and this is the primary way I get my materials to them. I do this in part because I find conventional consulting deliverables—documents, spreadsheets, and slide decks—to be undesirably opaque and clunky: opaque because of the way these artifacts tend to just magically appear on the deadline (if lucky) fully-formed, but until then the story is “trust us, we’re working on it”. So I’ve been looking to use the Web to help increase the feeling, on the part of the client, that real progress is happening on an ongoing basis.
As for clunky, I mean this in a few ways. For one, documents, spreadsheets, and slide decks often share a lot of the same content. It’s difficult to impossible to share content between these kinds of artifacts without outright copying it. Whenever you copy content, you risk introducing mistakes, and/or creating opportunities for things to fall out of sync. Moreover, I find that very few stakeholders need to see everything, and I would like to develop better ways to segment what I create by audience, so I waste less of their time. So, in the interest of accuracy, as well as to maximize the utility of my work product, I’m endeavouring these days to organize all information that I gather and/or generate, that can take on a formal structure, in the most finely-sliced, computable way I know. From there I can project it into more conventional formats when necessary. To do this, though, I really need a flexible master format, and that means the Web.
For example, on a recent project I generated a PDF out of all of the material I wrote on the extranet, and it turned into a 245-page book. I doubt anybody will actually read that book when they have the extranet instead, but it’s kind of like a totem to all the work that was completed.
I also anticipate another question from the audience which goes like “why don’t I just use Cloud Platform X™?” and the answer is the reason why you hire me is because I have informed opinions about these kinds of things, as well as the technical chops to be my own Cloud Platform X™. I also personally believe it’s unethical to force people into relationships with arbitrary third parties just so they can do business with me. (That said, if you’re already in a relationship with some preferred third party, that’s a different story: you’re the client after all.)
The Problem
Now, since I’m putting confidential client information on the open Web, I need some way to protect it. And while the site-specific security measures can vary in intensity, the median client is going to be okay with something stiff enough just to keep out the lookie-loos.
If there is a legitimate concern for targeted hacking, there are other things we can do.
The way to protect content in an information system is to create a list (or at least, what effectively ends up as a list) of who is allowed to access it. This is called authorization. But, for authorization to work, we need a mechanism for people to prove who they are, so we can determine whether they’re allowed access or not. This is called authentication. And the most common—and unimaginative—form of authentication is, undoubtedly, the password.
I have been a student of authentication and authorization (sometimes bundled under the umbrella concept of access control) for quite some time, dating back at least as far as 2005 when I worked at a (now-defunct) startup that was making a federated identity protocol—essentially a way to log into websites and populate common profile particulars, before that space got colonized by Apple, Google, and Facebook. At that job I had experienced something I hadn’t before: the head system administrator had actually taken the time to set up single sign-on for all the intra-office network services. So as long as you were in the office, unlocking your laptop meant unlocking everything else: e-mail, file shares, even Jira. That is, once you were logged in once, you were logged in everywhere. You didn’t ever have to put in a password, anywhere in the organization, save for your own computer’s lock screen.
Remember: this was seventeen years ago.
This experience left an indelible impression on me. We need access control to protect confidential information, we need authorization to do a decent job of access control, and we need authentication to do authorization. There has been a mountain of innovation in authentication methods in the last two decades. Why are we still torturing people with passwords?
My hypothesis is mainly that passwords are fairly well-understood and relatively easy to implement. Plus there are piles of off-the-shelf implementations, so that work is largely already done. Moreover I wager most product people don’t even think about alternatives, and just kinda go on autopilot. Then, later on, the password infrastructure is dug in like a tick, and it becomes a whole Project™—that nobody has time for—to expand out to other authentication mechanisms.
I’m going to assert here that burdening people with yet another set of login credentials is not just rude, it’s an actual impediment to the uptake of your product. Not only that, you burden yourself: no matter how much infrastructure you create to automate the process (another burden), you will always be fielding calls for password-related problems. I cribbed my ex-sysadmin’s single sign-on technique for an intranet project I created for a long-time client, and everybody used it every day. The experience was completely seamless: You would open the intranet in the browser, and it would just know who you are. I am fairly confident it would not have gotten nearly as much use if people had to go through the extra step of logging in.
Furthermore, I never once heard a peep about creating accounts or passwords, because every employee already had an account—the one they used to get into their computer. I used to boast that this intranet didn’t even have a login screen—it never needed one. So this single sign-on business was also a self-interested move: it was much less work on my part.
Fast-forward to 2019, after several years no doubt of hemming and hawing about it, I decided to try to replicate this seamless experience, but for an extranet. The strategy I had used before wasn’t viable because being physically situated in an office (or on a virtual private network) is actually an integral part of the setup. On the open Web, we have to use a different mechanism.
The First Crack
The idea that I had—and I don’t claim it to be original—is that since the long tail of logging into Web properties is clicking on the “forgot my password” button, why not just dispense with the password altogether and use that? By “that”, I mean the special one-off link that (hopefully) lands in your e-mail inbox, that you click on, and it lets you onto the website. But instead of bringing you to a page where you change your password, it just…lets you on. So in mid-2019, over a couple of days, I quickly dashed off a stripped-down passwordless authenticator.
Later that year, I actually used my new toy in a pitch to a client. To my surprise, they balked at it. They believed we had put confidential information out on the open internet for anybody to see, despite our insistence that the information was no less secure than their own corporate e-mail accounts. This I attributed to the fact that, as I mentioned, the implementation was super stripped down, and I hadn’t done any user interface—rather, I was the user interface: I generated these links myself, and hand-delivered them to their recipients. Their experience was therefore too seamless: they never saw anything other than the result of a successful authentication process. The strategy I had adopted for inside the office was not appropriate for outside of it.
The Other Problem, and Ultimate Solution
I knew this was primarily an optics problem. I had to introduce some friction for people to understand that they were entering a restricted area. But that meant the little curio that I had completed in a day or two would have to be blown out into an entire Thing™. So I sat on it for two years.
I took another look at it around September of last year for an upcoming project, but decided it would be too much work to get ready in time, and I also had just relocated to Toronto and my milieu was terrifically chaotic. So I resolved to pick it up in December, when I was finished. But then, you know, life happened, so I only managed to sequester some time to flesh this sucker out in the last few weeks. So here it finally is: Forget Passwords.
Forget Passwords is a stand-alone authentication module that plugs directly into a Web server, and determines whether visitors are allowed access. It does this by recapitulating the “forgot my password” process, minus the password part. You hit anywhere in the protected area, it’ll ask you for your e-mail. Assuming you’re on the list, it’ll send you a link back to where you started, except you’ll be logged in.
Technical fine print: Security-wise, this mechanism should be no worse—and assuming the recipient’s e-mail is secure, arguably better—than
Basicauthentication over SSL. The big benefit for developers is that this module has been purposely designed to interact as minimally with the application stack as it can get away with, meaning you should be able to mix it in with pretty much anything, and it’ll just work. (Other people have made modules like this, albeit for specific frameworks. Mine purposely sits beneath the frameworks.)This module uses a lesser-known feature of the FastCGI protocol to do its thing, and plugs into Apache’s
mod_authnz_fcgi. It could theoretically plug into other things, but I’m not sure what other receiving-end implementations are out there. Nevertheless, this project gave me a mountain of other ideas, which I’ll have to catalogue in a separate technical document.
The bulk of the work of upgrading this little module naturally went into creating the user interface that should have existed in the first place. Amusingly, while there are only three states on the so-called happy path—”enter your e-mail”, “e-mail sent”, and the e-mail itself—there were another fifteen for distinct ways the process could screw up. Part of the reason why I had put off revisiting this little project was because I was pretty sure that would be the case, although I was even surprised by just how many failure states there ended up being: I expected maybe ten at the most. The rest of the time went toward modifying the main behaviour slightly, fleshing out the little command-line administrative tool, and fighting with a third-party parameter validation framework that unambiguously cost me way more time than it was intended to save. Ah, software.
I should also remark that the back-end interface, which is what I started with, is at least as important as the user interface. One of the important exercises was to think about the coupling, or lack of it, between the software that restricts the access, and the software (or just plain content) to which access is being restricted. I wrote about this general idea a while back under the term intelligent heterogeneity, which can be summed up as: you’re never going to have a single pristine software stack, so you might as well be smart about how different ones inevitably get mixed together. (Hint: the answer is open, standard protocols.)
What Forget Passwords does for me, not to mention my users, is lower the friction around sharing protected Web content—but as we saw, not too much! It enables me to share my work with clients, pitches with prospects, and other top-secret gadgets with collaborators and friends. It takes one very big standing issue off the table and makes it so I—and my users—no longer have to think about it. It doesn’t have to scale to a zillion—after all, it’s in the category of what Robin Sloan called “home-cooked software”. And in typical open-source fashion, I’m sharing it with whoever wants to use it as well.
I firmly believe that if you have an idea for how things should work, that isn’t on the current menu of products and services, you should do it, if for no other reason than to find out if it’s any good. The moment I installed my little module into production, I knew I had put it off for way too long, but I’m glad I have it now.
While this case study represents the more technical end of my repertoire, I still very much consider myself a (consulting) designer. I designed the software package I described here to enact a specific set of behaviours, intended to generate precise, qualitative, real-world business and user experience outcomes. I just happen to also be the person who wrote the code.
This project represents a progression from business concern (“make it easy for the right people to access protected content” + “keep it low-maintenance”), to stakeholder (“make it easy to admin” + “make it easy to integrate with whatever we’re running already”), to user (“make it feel secure” + “don’t make me think”). It then draws on 25 years of working with software and the Web, in just about every capacity, to execute.
We’re gonna get to look at projects like these a lot closer than my client work. When I talk about that, I have to be circumspect, but the full package goes something like this:
Inventories, dictionaries, maps: help you and your team get a sense of your surroundings; name things so that they can be addressed and discussed.
Epics: If you have a Tough Thing™ to tackle, I’m going to tell the story of how you’re going to tackle the Tough Thing™. (Dactylic hexameter costs extra.)
Toys for thinking: Trying things out to see how well they work. This project is an example of that. (Actually, it’s a little bit beefier.)
Your team is busy with your product, and you are busy with your team. I’m an outboard brain, ready to help you increase your situational awareness, or take on those nagging problems that nobody else has time for. I fuse the perspective of an outsider, with a killer vocabulary, and a quarter-century of experience. And, I’m leasable (what ends up being) by the month.
Seriously though: if it sounds like I can help you out—or help your boss out—please reach out.
This case study is something of a warm-up. The next one I’ll be doing is a deeper dive into the project I did last fall, which I touched on briefly in December. It may not be the absolute next newsletter, but it’ll be the next case study. Spoiler: it involves translating an entire company.