Choosing 2FA authenticator apps can be hard. Ars did it so you don’t have to

[Karlston]

Choosing 2FA authenticator apps can be hard. Ars did it so you don’t have to

Losing your 2FA codes can be bad. Having backups stolen can be worse. What to do?

Enlarge

Aurich & Hannah Lawson

163 with 114 posters participating

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.”

Thin blades

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 oversights, 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.

The good

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:

 

First image of article image gallery. Please visit the source link to see all 9+ images.

 

Close runner up

The security of Duo backups are roughly equivalent. Seeds are also encrypted on a phone using a recovery password the user chooses when first turning on the backup. The password never leaves the device, and only the encrypted seeds are stored on any servers. As is the case with Authy, without the password set during backup, the user will lose the seeds forever. Short of cracking the password—an endeavor that’s infeasible if not impossible when users choose a truly strong one—and somehow obtaining the encrypted seeds, there’s nothing Duo or anyone else can do to gain access to the all-important seeds in plaintext (the same is true for Authy and LastPass).

 

Another thing to like about Duo: Unlike other authenticators it doesn’t allow the use of SMS, voice, or an email address to verify someone is authorized to receive encrypted seeds. Taken together, all of these things give me relative confidence that the foundations of Duo’s recovery process is secure, while also being easy and quick.

 

The thing Gamache found more tenuous about Duo Mobile, particularly the Android version, was its method for storing encrypted seeds.

 

The iOS version of Duo stores them in the iCloud keychain, a region of Apple’s cloud service that Matt Green, a cryptography expert at Johns Hopkins University, told me even Apple employees can’t access. Restoring the seeds first requires a user to set up a new iPhone or iPad using the iCloud account password and then entering a 2FA code (under a mechanism that’s maintained by Apple and is independent of Duo). After all that, the user must enter the recovery password Duo required when first backing up the seeds. The process easily takes under 20 seconds.

 

Storage provided by the Android version of Duo isn’t quite as robust, but it’s still acceptable. It stores encrypted seeds in Google Drive, which technically means rogue Google employees—at least those with extremely high system privileges—could access the encrypted secrets. The same goes for law enforcement with a court order. (Unfortunately, Duo doesn’t make use of Google Cloud’s Titan platform, which provides roughly the same assurances of the iCloud keychain. Interestingly, the encrypted backup wasn’t visible in my or Gamache’s Drive accounts.)

 

Excluding insiders and law enforcement, the encrypted seeds backed up to Google Drive are acceptably hard for outsiders to obtain. To steal the encrypted seeds, hackers have to know the target’s Google account password and, when the account is protected by 2FA (which it really, really should), using a second factor of authentication. Of course, in this scenario, a physical security key has to be one of the second factors. In the event a user loses the phone and is in the process or restoring Duo, it’s possible to get locked out of the Google account, in which case the encrypted seeds won’t be available.

 

The insider and law-enforcement shortcoming for the Android version of Duo aside, there’s a reason some paranoid users may not like their encrypted seeds stored on any third-party server.

 

“It's more philosophical for me, though a deep dive is likely to back that up,” Gamache said. “Relying on the third parties to provide both confidentiality and availability is troublesome. One of the key principles of security is keeping the attack surface small. [Duo] adds a lot of attack surface with this, and it's surface that they don't control and can't fully understand.”

 

Some people may also be uncomfortable giving third-party apps, particularly one involving the security, access to iCloud or Google Drive accounts. “There is NO WAY in hell I would give any non-google app full access to my G-Drive,” the consultant added.

 

One other word of caution: Uninstalling the Duo app from an Android device will cause the encrypted seeds to be deleted from Google Drive. Before restoring to a new device, make sure that the authenticator remains installed on the old one. Duo has more details about backup and restore here. These images capture the flow of backing up TOTP seeds on the Pixel XL and later backing them.

 

First image of article image gallery. Please visit the source link to see all i9+ mages.

Last choice: LastPass

The authenticator from LogMeIn, maker of the password manager LastPass, uses a local-only encryption process that’s similar in rigor and mechanics to the one Authy describes. LogMeIn’s equally detailed technical writeup provides an in-the-weeds description of how it deploys its zero-knowledge design on Android. The method is slightly different on iOS because the authenticator there uses platform-level encryption only and relies on the keychain. (Unfortunately, I could find no such technical description for Duo Mobile.)

 

At the center is the master password LastPass uses to encrypt or decrypt password or TOTP seed vaults on the local device and store only the encrypted data on LastPass servers. To restore plain-text seeds on a new or additional device, users need only enter the master password and a code sent by SMS to the associated phone number.

 

There are two things that give me a less than enthusiastic response to this. The first is that, like Authy, LastPass allows SMS to receive a one-time code required during the restore process. In the event an attacker steals the password and performs a SIM swap (again, a severe but not unheard of event), the secrets are stolen.

 

The other thing that may give some people pause is the use of the master password to encrypt and decrypt the backup seeds. This design means that many users are likely entering this password dozens of times per day, both into their LastPass app and when logging into the LastPass website.

 

Recovery passwords required by Authy and Duo, by contrast, aren’t used any time other than when backing up and later restoring. While LastPass goes to great lengths to ensure it doesn’t know the master password, the chances of a fatal error occurring are higher when the passcode gets entered so often.

 

“LastPass is one cross site scripting failure, or cross site request forgery failure, away from causing customers to send their passwords to god knows where,” Gamache told me. LastPass engineers “force users to make the website password the same as their master password. All an attacker needs to do is swap out a tiny bit of javascript or HTML, and the user will post the password rather than a hash. Their use case conditions the user to enter that password a lot, so there is more risk of the user messing up as well.”

The not so good

The above three apps are of course far from the only options out there, so we walked through a few more. To start, Microsoft Authenticator was less impressive. While the backup and restore process was easy and quick, I was able to install seeds on a new phone with nothing more than (1) the Skype password I used when setting up the app and (2) a one-time number that was sent to an email address associated with the Skype account (users can use any type of Microsoft account). There was no password required to unlock or decrypt the seed data once it arrived on the new phone. That likely means there’s no end-to-end encryption and if so that leaves the process open to threats from insiders and law enforcement.

 

What’s more, outside attackers need only obtain two passwords—one for the Microsoft account and the other for the associated email account—to make off with the plaintext seeds. (Security can be improved by ensuring the associated email account is security with 2FA that uses a physical key.) The last concern: I could find no documentation explaining the security behind seed backups, and Microsoft representatives declined to answer any of my questions other than to refer to links here and here.

 

For users who already trust Microsoft with sensitive data and want the benefit of an authenticator that’s tightly coupled with other services they’re already using, the company’s authenticator is suitable. For the truly paranoid, there are better alternatives.

The ugly

The last app I’m including in this roundup is Google Authenticator. It provides no dedicated backup and restore mechanism when a device is lost, stolen, or breaks, although the Android version does offer a transfer method that’s designed to move seeds when a user upgrades to a new device and still has the old one. This restore works by using the old device to generate a QR code that represents all stored seeds. The user then scans the code with the new phone.

 

Gamache figured out a way to use this transfer method as a makeshift backup and restore, but the process isn’t pretty. It requires users to generate a QR image and scan it with a backup phone. The TOTPs will then be available on both devices. Users must repeat this process each time they enroll a new site. While the seeds are never transmitted to Google, the QR code contains the unencrypted seeds, meaning anyone who sees it has access to every single one of the seeds stored on the device.

 

While Google Authenticator is likely the most widely used authenticator, its lack of a viable backup and restore mechanism puts users at considerable risk in the event they lose their device. With newer authenticators offering better options, Google Authenticator users should consider making a change.

 

Once again, readers should keep in mind the point of all this: to think through the various backup options to decide which one makes the most sense. In no case should anyone infer that they shouldn’t use TOTP-based 2FA (although arguably 2FA using a physical security key is better). Even in the event an attacker makes off with the TOTPs, users are in no worse a position than if they hadn’t used 2FA at all.

 

The threat models for many readers won’t be as high as the one used in this roundup. So as long as you’re using a truly strong password, your backups will be safe whether you’re using authenticators from Duo, Auth, or LastPass. I’d ultimately stay away from Microsoft Authenticator, although for many people its security is acceptable. And using Google Authenticator should be avoided at all costs, lest users go through the excruciating experience Caltagirone did.

 

 

Source: Choosing 2FA authenticator apps can be hard. Ars did it so you don’t have to (Ars Technica)  

 

(To view the article's image galleries, please visit the above link)

[Edion Gecos]

The 2FA authenticator app that I use and would recommend is "andOTP":
https://github.com/andOTP/andOTP

 

Concerning backups in case your phone gets lost:

Besides a JavaScript-based (strictly local in-browser) decryption of password-protected backups, one of the other possible methods are OpenPGP-encrypted backups that can be easily decrypt on other devices or PCs via OpenPGP.

 

The Android app can also be installed from F-Droid (thus avoiding the Google Play Store):
https://f-droid.org/en/packages/org.shadowice.flocke.andotp/