10

My understanding is that if you use Authy, without backups/multi-device options, none of your account keys are stored on their servers. It all resides on your single device.

Ie, even if Authy servers get hacked and all their data is compromised, and the attacker knows your gmail password, he will still not be able to access your gmail account because he doesn't know your "Google 2FA keys."

If you use the multi-device mode on Authy, is this still true?

Reading through their blog post (http://blog.authy.com/multi-device) and the functionality description, I suspect not. In order for your multiple devices to be synced with one another, their backend servers will need to know your gmail 2FA key, and redistribute it to all your devices as needed. This implies that if their servers get hacked and their data is compromised, your gmail account will be compromised as well.

Is my assumption accurate? If an attacker knows my gmail password, and is also able to hack into Authy's server/database, and I'm using the multi-device option, would the hacker then be able to access my gmail account?

8

At least in the latest versions of Authy's Android application authenticator tokens, such as your Gmail TOTP, are sent to api.authy.com only after being encrypted using an AES key derived from your backup password and a randomly generated salt using PBKDF2.

According to this source information sent from the API to your mobile phone has the following format:

 {
 "account_type": "gmail", 
 "encrypted_seed": "UZNL+UPVK+5RYUoBlhkuQzCcOb3nMdYxKGFmHEZ4TMxTX7MOPJUayQAMDVJ", 
 "name": "My Gmail Account", 
 "original_name": "Google:someaccount@gmail.com", 
 "salt": "N2QqyJrn7cOHBqTY32uY1cL4IHCANm", 
 "unique_id": "0000000000"
 }, 

In other words, your Gmail TOTP secret seed should be safe with Authy even if they get compromised and the database is leaked.

2

First, remember that Authy allows you to use any TOTP token (like Google authenticator), but they also offer their own proprietary 2FA method. In Authy's method, the account provider must integrate Authy into their authentication mechanism, not just implement the TOTP standard. In this method, Authy issues the seeds, and this also allows them to support push notifications when you are trying to sign into one of your accounts that uses this method.

So for multi-device using the Authy method, the seed does not have to be shared because they can just issue a new one. But for a TOTP account, they can't issue a new seed--the account provider has to do that. So their solution is to store those for you in their servers, encrypted by what they call your backup password.

(This is also what allows you to recover your tokens if you lose your device.)

So see, they were storing those anyway if you had backups enabled. If you don't want them to store those seeds, then you can have backups and multi-device turned off, but then what's the point of using Authy over Google Authenticator? Even if Authy's servers are compromised, you're still the only person who knows your backup password (which is hopefully unique). It's a pretty good system IMO.

0

From the blog post itself they state that unlike Google Authenticator, the Authy system actually generates new, separate keys for each device. As such I don't see any reason that they would need to store them so an attacker compromising their database should not be able to access them.

An attacker who compromised one of your devices would have access to a set of keys unique to that device. Once you have revoked those keys they should not have access.

1
  • I don't think this is correct. I'm looking at my devices right now, and they are displaying the exact same security-code for the same app. This would imply that they are using the same key, which would imply that they need to be synced with one another. There is a separate master-key that enables Authy itself on the device, but that's only useful for a client-side vulnerability (stolen device etc), not for a server side vulnerability. – RvPr Sep 9 '15 at 10:17
0

See their blog post for clarification on this. Apparently all encryption and decryption happens on the device, not in the cloud. Encrypted seed keys, distinct IVs used in encrypting each key and the Salt used to hash the backup password (and potentially other information about the hashing mechanism used) are relayed to the server. If users forget their backup password, they cannot decrypt their keys imported on a new device.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.