As a former MSP (Managed Service Provider — a fancy name for a roaming system administrator), I find myself in the funny position of having a very good idea of how your average office employees take to login security, both in the workplace and at home, while being well connected with a number of people working on both big tech and open source security products. For this reason I have spent a lot of time over the years writing about passwords and 2FA and in general advocating for security practices that people will actually follow.
Despite what you may be read, even on FT (paywalled), login security is not a solved problem, and “the password” is far from a dead concept — it would be nice to call “the” password, as in the concept of having the one password used everywhere, dead but I don’t expect that’s going to work any time soon. But for the most part, logins with passwords are here to stay for a long, long time, in my opinion and experience, and I’m not alone.
Leaving aside the inane, obviously broken services that “log” you in by just providing them with an account ID or email, which are often made fun of in the security circles when they are found – and the vast majority of the time are smaller businesses that thought they would be able to save a ton of money by hiring someone’s cousin, or the teenager child of one of their friends – there’s actual big names out there going behind the idea of “passwordless login”, implemented by asking for an email address, and sending you a login link to it.
The other take for this is sites that implement OpenID Connect (which is based on OAuth 2.) As a user, you would see these sites as allowing you to sign up or sign in with your Google, Facebook, or Apple account — I understand that giving that third option is mandatory for apps on the Apple platform that want to provide the first two, but I have no idea how the actual requirement work out for those, so excuse me if I’m incorrect. As I wrote back in 2014, OAuth 2 is actually a fairly decent solution if you don’t want to store user passwords, and instead just rely on a third party to handle the authentication for you.
Up to now this sounds like it’s pretty impressively stacked in favour of passwordless logins being not just feasible, but already here! Except there’s a lot to unpack before that. First of all, all of these solutions still rely on something being authenticated with a password: either your email account, or your OpenID provider, be it Apple, Facebook, Google, Twitch, Twitter, … This makes it not much easier than the solution of using a password manager, where you end up with a single passphrase to remember, and everything else is contained there.
Besides that, both solutions rely on the availability of third parties services. This is obvious for OAuth 2, but applies just as much (if not more) with email-based logins, as they rely on the ability of the service to successfully send an email, and for you to retrieve it. If you have any insight of how global email infrastructure works, you’re aware that most of it is based around batch processing, with queueing, and antispam measures such as graylisting, and source reputation.
This brings complaints such as Troy Hunt’s on the time to wait for an email to arrive: it’s not just a matter of their backend to be able to deliver this to the inbound backend of your email provider, but for that inbound backend to process it, make it ready for you to read, and send you a notification for it — on mobile phones, email notification is usually sent through push channels that are unlikely to be in the hot path of the email receipt, when they are even owned by the same company!
On top of this, there’s the question of whether the link completes an authentication flow, or if instead it is the authentication flow itself. In the latter case, you will be logged in on whichever device you clicked the link from — which makes it very hard to log into apps from devices that don’t have an email client (or at least don’t have your used email logged in on them).
Both of these drawbacks are in stark contrast with an “old school” approach with a password manager: unlocking 1password with a fingerprint and letting it fill in my username and password takes seconds, and does not require a context switch (which on a phone may cause your app to be dropped from memory, if you don’t have a very recent device), and if I do have to log in on, say, my TV, I can do that relatively easily — though I still long for an HID emulation dongle!
When it comes to infrastructure limitation, OpenID Connect is strictly better: you still rely on third party infrastructure (the OAuth 2 provider’s), but that is infrastructure that is designed and monitored to work as an interactive, real-time, high-availability endpoint (no queuing of messages there!), and with anti-spam protections that make more sense (reputation should be checked on the requesting IP, not the source of the email.)
Logging in with an OAuth 2 provider is usually as fast, if not faster, than using a password manager, assuming you’re actually logged in to the provider in the same device and browser session. Where things do get more complicated is logging in on devices (and sessions) that don’t have your provider logged in. As it turns out, OAuth 2 does include specifications for logging in on devices that don’t have the usual inputs, which both Google and Facebook support and document, but it is aimed particularly at devices such as TVs and game consoles that wouldn’t otherwise have a logged in account.
But, it turns out, implementing OpenID Connect correctly is hard, and in my experience most of the developers out there do not do it correctly. I know I’m oversimplifying here, but at a high level, once your user has signed up via one such provider, you’re meant to store a provider-defined account identifier (which may or may not be different for the same user from different requesters) to let them log in again later, and you are allowed to retrieve an email address to use for communication — and this is where Apple does something different from the others, if I remember the details correctly, as they provide not the actual user email, but an anonymized, per-requester alias, to prevent an user to be tracked across sites.
This is meant to allow users to change the email address they use for a service so that it does not match the original provider, as well as allowing to change which email address is associated with the account at the provider level… but in my experience it backfires more often than not. As I said when I was forced to abandon my old email address, a number of providers have forgotten that users can change their Google Account email address (particularly when it’s not a Gmail address), and indeed I still have not regained access to my Ingress account!
As an aside, I have no idea how Apple’s alias selection ends up working: the problem I can see is that to the best of my knowledge the way to distinguish between requestors is by API Key — which is why the authentication is usually done through API Key and secret: the secret can be rotated, while keeping the API Key the same. But too often I found websites deciding to use a new API key for their authentication when launching a new version of the web app, maybe because it’s developed by a different contractor. I have no idea how that interacts with Apple’s custom aliases, when the websites also use the email address as account itdentifier.
Of course, even with the already stated pros and cons of using this type of authentication, there’s the elephant in the room: any passwordless implementation delegates to third party infrastructure one of the most critical components of account management. This may be intentional, particularly for smaller sites (after all, as I wrote back in 2013, I really don’t want to have to register with a password for each blog out there!) but it starts making a lot less sense as the service collects more personal, sensitive data.
From the service point of view, delegating the authentication to third parties means your users can protect themselves with 2FA or U2F without you having to implement those (possibly complex) flows, as well as not painting the huge target on your back for storing passwords that can easily be used in password stuffing attacks. But if your database still includes addresses and phone numbers, you are already a target.
That leaves the option of not bothering with the complexity of U2F/Webauthn (nobody should waste time with 2FA in 2021), and accepting that third parties will control whether your users can use the service or not. The problem here is not just a matter of “buying in a bakery“, it’s a matter of reliability.
Last year, an incident affected the Google authentication backend, leaving basically the totality of their users unable to access their account (YouTube, Gmail, Drive, …), as well as any account relying on Google for login. Last month Facebook (my employer) had an incident that took down the service for a number of hours, leaving the totality of our users unable to access their account (Facebook itself, Instagram, WhatsApp, …), as as well as any account relying on Facebook for login. Last week, Fastmail was subject to a DDoS, leaving some of their users unable to access their account by web, as well as any account relying on email for login.
Again, I do not think that the right answer to this is to only run in-house self-hosted systems. Indeed, these are big and visible exceptions for infrastructure that is generally a lot more solid and more reliable than your average self-hosted mail server (with exceptions in the handful of geeks who happen to have the expertise and time to run their own servers) but I do think that it’s worth asking yourself if this whole “passwordless” trend is actually serving your business needs, or just risks getting your users to be let down by third party outages.
