If you could rebuild user authentication on the web from the ground up, what would you do?
lou's post here resonated with me and my attempts to get my family to use better security practices (i.e. 2FA, password managers). They're very difficult to wrap your brain around to the average user, and they have the ability to create catastrophic failstates if used incorrectly. Furthermore, even when they work well, they can still be kind of clunky (different sites use different methods; writing down/printing recovery codes feels like a dated solution alongside other tech-forward things).
Also, outside of this, password requirements are their own bugbear, with nearly every site having different criteria. Even as someone who uses a password generator and manager on the regular, I still have to adjust the password creation criteria to do things like fit character limits or specific requirements (and don't get me started on forced resets!). I totally get why so many people reuse passwords, or have a default one that they sort of modify as needed to fit a given site's needs.
From my (admittedly super limited) perspective of a lay user: usernames, passwords, 2FA and the whole stack seems like something that's suffering under the technical debt of decades' worth of web development and networking. It seems like things have inched forward and many new layers have been added to address emergent problems, but the whole system gives a sort of barely-held-together-by-tape feel.
What if we could use what we know now and redesign things from the ground up? If we could start fresh, today, what might username authentication look like beyond the usual username/password combos that we're so used to?
I'm interested in any ideas -- not necessarily just feasible ones.
Also, despite me being the one prompting this thread, don't feel the need to simplify technical explanations or anything. I'm mostly interested in lurking and seeing what all you very smart techy people have to say about the topic. :)
@balooga brought up SQRL the last time a similar topic came up. The TL;DR of it is:
Two factor authentication as implemented has always rubbed me the wrong way because of many providers only offering SMS (looking at you, banks) which is horribly broken (and collects personal information), its vulnerability to phishing attacks, and just how easy it is to get locked out (cc. lou's mother).
The web is currently moving in a good direction with FIDO, which is vaguely similar to SQRL, but markets itself as being less susceptable to phishing attacks (a clear and present danger with SQRL, as implemented). I know less about this protocol - surface level differences seem to be individual public/private keypairs per website per device, which strikes me as more flexible than SQRL's one-and-only keypair - but it has strong industry support and has recently become a web standard.
I forgot about SQRL. Is a zk proof practical these days? Also, the protocol defined some sort of password manager with master key, but I believe the auth key sent over was site specific.
https://webauthn.io/ basically does what I want; asymmetric keys with a nice user experience. It's supported in the main browsers, but the documentation and infrastructure needs a bit of work.
The problems you’re describing are social in nature (no standardization, no central source of truth). We have great technical options in the form of hardware keys, PGP, etc.
In short, what we need is a central authority to tie “documentation of identity” to a gated communication channel. And weirdly enough, that does currently exist in a form: telecom providers. They just don’t offer a very secure channel and don’t do a great job vetting documentation of identity (or keeping youths from snatching the tablets of store managers) - hence SIM swaps and the like.
My dream solution would be a government-charted entity designed to act as a central identity management agent. A glorified pubkey registry backed by a responsive and regulated bureaucracy to handle the human element of things that can go wrong (lost recovery keys, name changes, yada-yada). Possible to make it into a government ID chipcard form - but I think it would be more palatable to the general public in a different form factor (phone-accessible .gov website?). Not likely to happen in the near future due to the politics, but it would be a huge boon to the public interest if it ever happens.
Edit: see petrichor’s FIDO link elsewhere in this thread for a full writeup of what I’m describing as a “pubkey registry service”.
Ohhh, that gives me the creeps. You'd tie my real-life identity to all my online activity. I don't think that's necessarily a good idea for the internet. Also, I wouldn't trust any government in the world not to eventually abuse that registry to spy on people.
Actually, let me get over my instinctual reaction and think for a second:
You're talking pubkey registry. We can probably design a reasonable system here. I assume you mean to set it up on a technical level so it can't be de-anonymized where it doesn't need to be? I.e. the state has very little, if at all, option to actually access my accounts, all they can do is mark my key as compromised. Can they create a new key and use it themselves, or can we find a way to prevent that? Well, whatever the case. I'm sure it can be done properly.
Then again, I don't trust most government to do it properly in the first place.
Huh, wow. If that's my initial reaction, and I understand PKI somewhat.... have fun explaining this system to the general public.
That's my other concern. If the government has sole control over the keyserver, nothing stopping a malicious actor from subbing in an invalid key.
Even if the government is trustworthy 99% of the time, that still leaves 3.5 million exposed to that vulnerability.
That’s not a new threat vector introduced by this system - it’s just identity theft. With this proposal, your threat model would change from anyone being able to open an account in your name via any service they desire, to having to infiltrate the federal government in order to do so. (Assuming an opt-in “credit freeze”-like system where financial orgs would be required to verify your identity through the central registry to open new accounts.)
Not just open, but also to access any that you already have. Including your communication methods like email. So not just identity theft, but "Identity theft AND all of your passwords."
And infiltrating the federal government isn't necessarily hard. Centralized ID management, particularly the front-line support that would need access to do these things, would likely be a very large department.
Much how we've already seen how various other law-enforcement and three-letter-agencies have abused the powers they have, I have 0 doubts that a government-as-sole-IDP would be heavily abused in a fairly quiet way.
Ah so you’re saying that if an attacker gets into your “key management” account they can reset everything?
That’s a fair point, but mitigable through something like a mandatory 3-day review window before any key actually get reset. Compare it to using a password manager - you’re putting your eggs in one basket, but it’s a much sturdier basket and a big improvement over the current MO.
Sole-IDP need not be the case - but I do think one should exist to foster a tech ecosystem built on public key infrastructure. I’d also be more willing to use login.gov OAuth with my bank account than ID.me - I simply trust a public institution to have less risk of infiltration, perverse financial incentives, and disruption than a private equivalent.
I have the same real-world take, but we’re talking pie-in-the-sky here 😉.
Yeah, I’m imagining one keypair being issued per service/account, either publicly under one’s name or anonymously. E.g. one per bank account, one for your cell provider account. (There are admittedly issues with nonrepudiation here that I’m ignoring so as to not get lost in the weeds.)
The use case I see is not to secure every single account through the government - but rather to give people a central avenue to securely sign up for important accounts (banking/utility/primary email/mortgage/medical portal), with the assurance to the business they’re registering with that any veil of anonymity can be pierced where necessary through legal action. In this model, the government would know your identity when you register the key, but wouldn’t need to pass it along. It also gives users the assurance that if they die, become incapacitated, or otherwise lose passwords and keys, their accounts won’t be gone forever.
In essence, this would be used as a better way to sign up the types of services that currently require an SSN. We’ve had PGP keys around for decades, and they already work great as-is for full anonymity - but they’re not practical for “normal” everyday usage because you’re SOL if you lose you private key in the current fully-anonymous models. A public registry would solve that operational challenge and make PKI more useful in day-to-day life. Given the general public has no problem using chip cards, I don’t think there would be much issue with people getting their heads around the system, because they wouldn’t need to - all the hard edges can be abstracted away by whatever software they’re using to interact with the .GOV registry.
And following up on your “can the government access your accounts” question: yes, that’s by design to prevent lockout.
What they couldn’t do is access your accounts without your knowledge - they’d have to reset your keys to do so. No spying at scale.
People are very suspicious of government in the US, but other countries are quite different and welcome nation wide identification. In some places, the step to make such IDs digital is almost trivial, from a political standpoint.
I was thinking half about the US “sovereign-citizen” types, but half about the general 1984-ish “papers, please” vibe that I’d expect to be a more global fear w.r.t. a centralized ID chip.
Totally with you though; it’s a fine form factor where people are okay with it.
I mean, the US already has that between RealID and passports. And SSN.
That said, having 1 central authority for authentication is kinda problematic for the same reason using the same password for every site is.
The problem is people are dumb, and are completely unwilling to recognize that RealID and SSNs already enable whatever nefarious nonsense they are afraid of while not providing any of the convenience or security a sane national ID would be capable of. We are literally getting the worst of both worlds here.
As far as I know, none of those support public key crypto.
What I'm talking about is essentially a "key server" service with the backing of the federal government. Your identity would be registered with this notary service, but wouldn't necessarily have to be shared publicly (though it would be subject to warrants).
How private keys are managed would be mostly arbitrary - but if they get lost, you have a central authority who can vouch for the user's identity and certify new keys.
https://en.wikipedia.org/wiki/Key_server_%28cryptographic%29
Oh, yea they don't have a pubkey chip. But as @babypuncher pointed out, there's really no reason they couldn't except irrational fear of further tracking.
I too love the idea of leveraging pubkey crypto as an alternative to traditional passwords. The biggest problem with it though is the 'single password for everything' problem. Fast revocation only goes so far.
The thing is, even with a good pubkey implementation, you should still have your private key passworded.
That’s a problem with current practice of PGP keys as we use them now. With a good wrapper to let people transparently make a new keypair per service they want to secure, that issue goes away.
IndieAuth.
One angle to attack it from could be more available bioauthentication - everyone loves the fingerprint readers and facial recognition software (e.g FaceID, since only Apple stuck with it) on their phones. It's quick, seamless, you can't lose it (ok, yes, you can lose fingerprints and faces but that is very much an edgecase, and if you lost your face I'd imagine you have bigger issues).
So perhaps if we were to restart, given the proliferation of cheap but effective fingerprint readers, all devices come with at least one bioauthentication source, and that is the default for authentication. A problem comes in how you make that portable, without also leading the possibility of having the credentials be stolen (it's a lot harder to change your fingerprints than a password).
Note that when used for two-factor auth today, fingerprint readers don't send the fingerprint over the network to the remote website. The fingerprint reader contains the user's fingerprint and a private key in its memory, and it never exposes these two things to the outside world. The computer sends some data to the fingerprint reader to sign using its private key, and the fingerprint reader only does that if it reads a match from its scanner to the stored fingerprint.
If someone knows your fingerprint, they can't use that by itself to bypass your two-factor auth. They have to steal one of your two-factor auth devices and then convince it that it's reading your fingerprint. If you have a two-factor auth device stolen, you could remove it from your accounts on websites so it can't be used against you. (Ideally there would be a way to do that in one place instead of having to do that on every single website you've paired it with.) If you think you're targeted by people capable of bypassing fingerprint readers and stealing it from you, then you could use an alternative two-factor auth device that asks for a cryptographically-strong password and uses that to decrypt a private key, so that way even if it's stolen an attacker can't get anything out of it.
I think a better way of framing this idea is that websites should rely on public key cryptography through two-factor auth devices, and fingerprint readers are a specific kind of two-factor auth device. Most users could use two-factor auth devices that use some local bioauth (fingerprint, faceid, voice, etc), but anything that works with the protocol is fine and stronger (and weaker) choices exist.
Therein lies the issue, however. That makes it no longer portable. Just conceptually it's not really possible to be portable without transmitting the raw credential at some point.
If I create an account on Youtube with my fingerprint on my phone, I cannot unlock it with my fingerprint on my laptop (well, hypothetically tightly integrated devices like an iPhone and a mac could, but that's a limited number of pairings). You would need to authorize yourself again on that device to register your bioauthentication.
That may just the tradeoff people need to make. Consolidation of authentication with OAuth could make this not a particularly painful process at all.
If sites actually used your fingerprint data directly, then anyone that's gotten your fingerprint from anywhere in real life could use it to log in to any site as you. Anyone could walk through a town picking items from trash cans and get into thousands of people's accounts forever.
The main annoying thing today about getting a new two-factor auth device is telling many websites over time about your new device with your old device present too. If this was streamlined, so that you paired your new auth device with your old auth device one time, and then your new auth device worked everywhere your old one did, then it's only a tiny annoyance setting up a new auth device. I expect this kind of streamlining to eventually happen as two-factor auth devices get more popular with websites and the webauthn standard evolves.
Just thinking about the notions of the need/use for/accountability of a central authority.
Previously, when security was physical (locks and keys and safes etc), there tended to be a few central, private, authorities (yale locks), subject to various vulnerabilities (stealing/reverse engineering the master key designs, e.g.), as well as stability (I think Yale has gone out of business at least once). And there's a lot of trust placed in locksmiths, without clear regulation. An individual trying to keep small items (papers) secret would have to rely on third party vendors plus some degree of ingenuity, like disguising a safe.
There is also the Federal Reserve. A quasi government entity with enormous power and central responsibility for something that greatly afffects every citizen, and kinda sorta works OK. Note I am not advocating that the Federal Reserve itself should administer any kind of digital security infrastructure. But surely some of its foundational structures could be emulated in the digital security space to create some kind of functional and reasonably secure (from rathscallions as well as governments) central organizer.
The top priority IMO should be to better work with the delicate meatball that is the end user, because they've got things to do and don't have a lot of time to waste with complicated passwords systems and different requirements for different sites. Get things simplified, KISS.
I cannot tell you how hard I roll my eyes when someone fails the security questions and gets annoyed and wants to speak to a manager because they have enough details of their A/Cs, but not the specific parts we need.
Some security questions are confusing and poorly worded for too many ppl, particularly the elderly, who don't trust online or mobile banking and get stranded more easily as a result - seriously, get a backup account and debit card!
Well, I'll reiterate: if you're going to make 2 factor authentication basically mandatory, you should make sure to inform your user, in no uncertain terms, exactly what can happen if they:
Most regular (non techie) people are too used to the notion that knowing your password should be enough. They'll just go through the motions to use their account without jumping through a lot of hoops.
It shouldn't be a "secret" that if you don't have 2 or 3 failsafes in place, there's a chance that you'll lose access to a large portion of your online life. Sure, hackers are a menace, but I'd bet good money that my hypothetical grandma would have a greater chance of locking herself out of her accounts than from being victim of a targeted cyber attack.
I really wish all sites had a two-sided authentication --- where the server has part of a key that goes with my key (from a Yubi etc). My key is sent to them and their key is sent to me. If we match up, authentication is valid, otherwise its rejected.
Both sides have rolling keys. I'm just spitballing, but I think a method like this would work well to prevent some vectors.
I’d say the problem is the lack of a way to force straightforward 2FA on people wherever they are. If I was designing the social problem away from the ground up I would have actually had the vast majority of services authenticate you via a “magic link” to a messaging service that exists only for account creation and authentication purposes. This account should be locked down with the strongest security measures possible. It should work like email.
This is similar to how RSA works without the fiddly number thing. And it spares us the trouble of even having to manage passwords at all. The one password people will need to remember can be simple since it’s only one of multiple factors of authentication.
I’d also have the government provide user ID chips that people can have put into whatever personal token or totem they want by, like, a jeweler or something. This should work with some sort of NFC standard that can be used to authenticate you for more official, in-person transactions like with the bank or government services. Similar to the Aadhar card in India, but cooler because it’s more personalizable.