Why Keybase Doesn’t Offer Two Factor Authentication
Credit to Author: Lily Hay Newman| Date: Fri, 25 Oct 2019 11:00:00 +0000
Keybase exists to keep things safe online. And it doesn't use 2FA to do it.
When you think of online security, hopefully by now two-factor authentication springs to mind. WIRED certainly pushes the feature every chance we get. And for good reason! It's a solid protection against common web attacks like phishing and credential stuffing. But when Chris Coyne and Max Krohn, who previously cofounded OKCupid, launched their own digital identity and encrypted chat platform in 2014, they decided against using 2FA at all. Which is less radical than it sounds.
The company, called Keybase, is open source and audited by (paid) third parties, but users and two-factor authentication advocates often ding the company for not offering 2FA. Keybase says, though, that conventional two-factor wouldn't protect Keybase accounts in the way you might think. And if you look closely, you'll notice that many similarly sensitive products, like password managers or secure messaging apps like Signal, often don't offer conventional two-factor either.
"The two-factor authentication people usually talk about just doesn't make sense with the model of how Keybase works," says Krohn.
Two-factor authentication is a specific tool with a lot of important uses, but it's not a one-size-fits-all solution to every data security issue. "People have misconceptions of how 2FA works in the context of encryption or things like password vaults," says Maximilian Golla, a researcher at the Max Planck Institute for Cyber Security and Privacy in Germany. "If this tells us anything, it's that the topic is rather complicated. I don't expect most people to automatically understand what's going on here."
You probably intuitively know how most web services are set up. Data typically lives on an internet-connected server that you access through a web browser. If it's sensitive data, a password protects it so that only authorized people can access it, but they can still pull it up on the go. The magic of the internet!
When you provide those login credentials to a server, you are "authenticating" yourself, essentially saying "It is I! A person who is allowed to access this data." The server checks the password you provide against the password it has on record next to your name—like a bouncer at an exclusive club—and if they match, you're good.
"There are special cases where it offers much less security than implied."
Jeffrey Goldberg, AgilBits
You almost certainly know from experience that this system is very flawed. It's hard to store a lot of passwords in your head, so you choose things that are easy to remember, or use the same password again and again. (Don't do that.) And if someone can steal or guess your password—pretty easy when you reuse one, or set it as your birthday and pet's name—they can use it to log into places as you. Which is bad.
So over the years a solution has evolved: a second level of authentication after the password. And by the time the idea took hold, a lot had changed in the digital world. Namely, smartphones. So the two factors of web authentication became "something you know," your password, and "something you have," a phone that gives you a numeric code from a text message or a code-generating app.
This authentication setup still has problems—for example, you can still be tricked into handing over both your password and your two-factor code to clever phishers—but overall it's a huge improvement. It's just not the only improvement. The rise of smartphones and other technological advances have also made it possible to fundamentally set up web services differently, allowing people to move past the old concept of passwords and two-factor altogether. Instead of being on the bouncer's list at the club, all you need to know is how to throw a good house party.
Keybase is end-to-end encrypted, meaning that data is only ever understandable at either end of an interaction, like the two smartphones in a messaging thread. The rest of the time, whether the data is in transit across the web or sitting on Keybase's servers, no one—including Keybase—can read it. (Some encrypted platforms, like Signal, go a step further by not storing data at all.) Instead, you need the ability to decrypt data locally on your devices. That's the house party.
In these arrangements, services use a system called "public/private key authentication," in which each user has two long alphanumeric strings assigned to their account—one secret, one openly shared—that enable data encryption and decryption. A company like Keybase stores the public keys of all of its customers, and uses that information to make sure that data goes to the right places and everyone has the features and functionality they need. But only individual users hold their private key. No one else has it. So if you break into the Keybase servers you won't accomplish much, because all the data is encrypted and only public keys are lying around. Without the private key, all of that is useless.
This is where alternative authentication schemes kick into high gear. Let's say that the first time you ever set up Keybase you make the account on your phone. If you also want to access your account on your laptop or tablet, you can't do so through a browser. Instead, you go through an "Add a Device" process (typically involving a QR code) in which you use that already trusted phone to authenticate yourself and anoint the second device as well. In a lot of schemes, like Keybase's, every new device you add gets a different private key. It's all part of one account, but you're not reusing the same key again and again.
There are some pretty clear pitfalls to putting so much faith in your devices. You can lose them, for one, and if you misplace your trusted devices it becomes tricky to get back into your account. (Keybase encourages users to make "paper keys" where you write down a long series of randomly generated words you can use to recover your account, and store that paper in a safe place.) And while you don't need to worry about someone guessing your password—or breaking into a server and stealing everyone's passwords—things do get complicated if someone steals your trusted device or compromises it with malware.
The answer lies not in traditional 2FA but in extra layers of protections when adding a new device to your trust chain. For example, Signal offers the option to create a "Registration Lock," a PIN you need to enter to reactivate your Signal account on the same phone number if it's been dormant. It also has a "Screen Lock" feature that requires you to use your phone's passcode or biometric unlock to access Signal after it's been idle for a certain amount of time. Keybase has a limited browser-based portal, and it offers a "lockdown mode" to prevent any account changes from originating there. And password managers like 1Password have increasingly added support for extra protections like a Yubikey or other physical token when you add your account to a new device.
Keybase's Krohn stresses the importance of general device encryption—like a PIN, fingerprint, or face lock—on every phone and laptop. He points out that end-to-end encryption isn't meant to protect a user if an attacker has full device access through malware anyway, so the most important type of attack to focus on guarding against for a service like Keybase is a physical access attack.
"We truly believe that a phone with a private key that never leaves the device is a better authentication mechanism than password plus one-time code," Krohn says.
Whether it's a registration lock or a Yubikey, these extra account protections are additional authentication factors, but not "authentication" in the sense of interacting with a server. That distinction is where a lot of the esoteric—but still dramatic!—debates crop up. But it's also why Keybase doesn't offer what's normally called two-factor authentication.
"People correctly see 2FA as a valuable security measure and it really is in many cases, but they often don't recognize that there are special cases where it offers much less security than implied," says Jeffrey Goldberg, a product security officer at AgileBits, which makes 1Password. "For a system like 1Password, the addition of 2FA is not a substitute for a strong password, as 2FA and a good master password protect from different threats."
Though passwords are one of humanity's most epic self-inflicted dumpster fires, web server security has genuinely come a long way. There are still a lot of web services that can really only run on the traditional model, and that's not necessarily a security problem if the right protections are in place. But the more decentralized approach that services like Keybase take has some definite security advantages in terms of minimizing the possibility of remote account access.
So should developers attempt to transition to away from traditional 2FA? Researchers say that it's hard to tell. Everything that played out with password insecurity seems obvious in hindsight, but it's difficult to predict the full consequences of a user authentication scheme when no one knows for sure where computing will go next.
"I don't disagree that that setup has its benefits," says Matthew Green, a cryptographer at Johns Hopkins University. "How much better is it? I don't know."