Last year, Sergio Caltagirone found himself in a tough spot. While traveling, his phone broke and stopped working completely. With no access to his Google and Microsoft authenticator apps, he lost access to two-factor authentication when he needed it most—when he was logging in from IP addresses not recognized by the 30 to 40 sites he had enrolled.
“I had a whole bunch of sites [that] I had to go through a massively long account restoration process because I lost my 2FA,” said Caltagirone, who is senior VP of threat intelligence at security firm Dragos. “Every time, I had to contact customer service. I had different levels of requirements I had to go through for them to effectively disable 2FA on my account. Some required address verification. [For others,] I had to send a last bill. The number of those I went through was just insane.”
The experience shows the double-edged sword of multi-factor authentication. Requiring users to enter a password that’s pseudorandomly generated every 30 seconds makes account takeovers significantly harder, even when an attacker has phished or otherwise obtained the password. But in the event that second factor (in this case, the “something you have,” that is, the phone) isn’t available, that same protection can block legitimate users from logging in for unacceptably long periods of time.
When Caltagirone relayed his experience last September, a quick survey of the available consumer and small-business authenticators left much to be desired. Only a few of them made it possible to back up the unique cryptographic seeds that each phone uses to generate a time-based one-time password, or TOTP. Websites—including Google, Github, Facebook, and hundreds of others that implement the Time-Based One-Time Password Algorithm standard—require the temporary password to log in users who opt in to 2FA.
The result? When your device was stolen, lost, or stopped working, you had to go through the same painful and time-consuming account recoveries Caltagirone did. The lack of a backup and recovery mechanism meant the only viable way to hedge against a device loss or malfunction was to print, scan, or photograph each QR code or the underlying Web link (for instance, http://[email protected]/?secret=LZZIKRWX736EH2IQ&issuer=Slack) it represented. That was time consuming. Even worse, it was cumbersome and insecure to store them, particularly when traveling.
Unfortunately, there’s a double-edged TOTP sword that’s equally vexing. By storing them on someone else’s server, sometimes with only a password and SMS-verification required to restore them, they are vulnerable to theft, at least in the more rigorous threat model scenarios. I tested Authy, Duo Mobile,LastPass Authenticator, Microsoft Authenticator, and Google Authenticator and found that all except for Google Authenticator offered a viable means for backing up TOTP seeds and recovering them in the event the phone or other device was lost.
The security was passable for all four of the authenticators that offered recovery, but each one also has weaknesses that in extreme cases make them vulnerable to (depending on the app) hackers, malicious insiders, or law enforcement agencies with a court order. I thought through such scenarios and the risk-benefit analysis of each authenticator with invaluable help from Mark Gamache, a Seattle-area security professional focused on applied cryptography and authentication.
Assessing the security, modeling the threat
Nothing in this post should be construed to say people shouldn’t use 2FA. Even with backups turned on, using TOTP-based 2FA is without a doubt better than not using 2FA. And it’s important to remember here, as with any security assessment, that there’s no one size fits all. What’s most secure for one person isn’t necessarily true for another. This round-up is less about telling readers which authenticator backup is the most secure and more about helping readers think through all the various considerations.
One of the threat models Gamache and I assumed is a hacker (1) successfully obtaining a password through phishing or other means (after all, that’s the scenario that 2FA, by definition, anticipates) and (2) taking control of a user’s phone number through a SIM swap or other means. While these requirements are steep, they’re not unheard of, particularly against targets with large amounts of Bitcoin stored in online wallets.
Additional threats include a malicious insider at one of the authenticator services or a government agency who either steals confidential data or compels that it be turned over. Again, these are extreme scenarios, but not unheard of.
Ultimately, I settled on three authenticators—Authy, Duo and LastPass—because they gave me confidence that, absent unknown software bugs or cryptographical oversites, their backup and recovery processes worked using zero knowledge. The principle means that secret TOTP seeds are never available to anyone other than the end user. The assurance requires that all encryption and decryption is performed on the client’s local device, and the data is encrypted both in-transit and at rest on the provider’s servers.
The two authenticators that stood out were Duo and Authy. Both made backups easy, and gave me a reasonable level of confidence that they would keep the secret seeds secure and confidential under my threat models. Both authenticators focus primarily on enterprise customers, who pay to use them to log large numbers of employees into corporate portals and private networks.
Makers of both authenticators provide a suite of additional security services that go well beyond 2FA, such as helping administrators track which of their thousands of employees’ devices haven’t installed security updates. Duo Security and the company behind Authy (called Authy) also offer a free authenticator version that works with any third-party site that uses the TOTP standard, and that’s the focus of this roundup.
Authy was my top choice because the backup pushes encrypted seeds to multiple devices, including Macs, PCs, tablets, spare phones, or Linux machines. The seeds are then synced among all the devices such that a change or addition on one device will automatically be populated to all the others. In the event a user loses one device, her other devices will continue to produce TOTPs. The seeds can then be added to the replacement device.
Besides providing the assurance of a robust way to backup and restore, this method provides the convenience of having multiple working authenticators and of using them from a much wider range of devices than is possible with the other authenticators in this roundup. (Duo allowed me to use multiple phones, but they all had to run either Android or iOS. Also, changes or additions made on one device didn’t sync with the others.)
Authy users set up a password during the backup process that encrypts seeds on the device before sending them to Authy servers. Without the password, seeds can not be decrypted and are lost forever. Without going through a rigorous recovery process (more about that later), users can’t receive the encrypted seed data from Twilio without demonstrating control of the original device or phone number used when setting up the authenticator.
Another plus: Authy goes to greater lengths than all but one other authenticator in documenting how seeds are encrypted on a device. The Authy mechanism adds a randomized cryptographic salt to the user-chosen passcode and then passes it through at least 1,000 rounds of PBKDF2, an algorithm that’s among the best at thwarting password cracking attacks that use either word lists or brute forcing to guess the password.
The resulting hash is used to generate a key that uses the time-tested Advanced Encryption Standard to encrypt the seeds. The process also adds an initialization vector for each enrolled account. Only after this process is carried out locally, meaning on the user device, are the encrypted seed, salt, and IV sent to Twilio.
The result: Twilio has no ability to store or even see the backup password and hence has no ability to decrypt the seed data. After receiving the salt, IV, and encrypted, the Twilio server will send the data to authorized backup devices. The user then enters the backup password on each device as the last missing piece to decrypt the seed. (The value of the salt/IV is to provide another layer of security in the event an attacker manages to steal the encrypted seed from Twilio, but not the salt/IV.)
In the event a user loses all of their devices but still has control of the phone number, the user must go through an account recovery process that includes a mandatory waiting period to recover the encrypted seed data. In the event the user loses both the phone and the phone number first used to set up Authy, the recovery process will be more involved and may require producing a government-issued ID, among other things. Once again, though, none of this will help in the event the recovery password is lost.
The thing I liked least about Authy is its use of SMS or voice calls to verify a new device is authorized to receive encrypted seeds. This means that knowledge of the backup password and a SIM swap are all that’s needed to recover and decrypt the data. To be clear, this is an extreme threat model, and other authenticators similarly allow SMS or an email address for verification.
Authy has more details on the backup and restore processes here. Here’s the flow when using a Pixel XL as the primary device and backing up and syncing to a Windows laptop: