A few years ago Google Authenticator released an update for their iPhone App that wiped users 2FA keys when installed. That prompted a lot of users to switch to Authy in order to take advantage of our key backup feature. We occasionally get questions about this particular feature from both users and developers, so this post will explain how the backup feature works in order to assuage any security or privacy concerns.
Backups are opt-in!
If you do not enable backups, your accounts will only be stored inside your phone (just like most other 2FA apps). You are not required to sync your keys to Authy in order to use your phone as a second factor. If you don’t need the convenience of backups, no problem — simply keep backups disabled.
Backups are encrypted prior to upload
Let’s set the record straight on how we handle encryption. For your convenience, Authy can store an encrypted copy of your Authenticator accounts in the cloud. The account is encrypted/decrypted inside your phone, so neither Authy or anyone affiliated with Authy have access to your accounts.
To make backups compatible across devices, all Authy iOS, Android, and desktop apps use the same method for encryption/decryption. (Apologies to users if this part of the post gets a bit technical, but developers will get it.)
How the Authy key backups work:
Backups are executed in several steps:
- We ask you to enter a password. Passwords must be 6 characters long, although we recommend that you aim for at least 8 characters.
- Your password is then salted and run through a key derivation function called PBKDF2, which stands for Password-Based Key Derivation Function 2. PBKDF2 is a key stretching algorithm used to hash passwords in such a way that brute-force attacks are less effective. The details of how this is done are quite important:
- We use SHA-256, a secure hash algorithm that is is one of the strongest hash functions available. It’s a one-way function – it cannot be decrypted back and is one of the strongest hash functions available.
- We use 1000 rounds. This number will increase as the low range Android phone’s processor power increases.
- We salt the password before starting the 1000 rounds.
- The salt is generated using a secure random value.
- Using the derived key, each authenticator key is encrypted with Advanced Encryption Standard AES-256, in Cipher Block Chaining (CBC) mode along with a different initialization vector (IV) for each account. To make each message unique, an IV must be used in the first block.
- If any Authenticator keys are 128 bits or less, we pad them using PKCS#5.
- Only the encrypted result, salt, and IV are sent to Authy. The encryption/decryption key is never transmitted.
Restoring Authy Keys:
If you have a new phone — or are adding a new device — you can restore your Authy keys by following these steps:
- First install Authy on your new device.
- Next, use Authy to confirm you are the owner of the original account. You’ll want to use the original phone number and country code you used when initially signing up for Authy.
- You’ll receive a OneCode notification on another device (SMS or Voice) and will be required to enter that value before your keys sync. Once your keys have synced, you will have to provide your backup password to decrypt your keys.
- Note, the Authy keys on this new device use a different TOTP seed value so the codes provided will be different on each device.
- For Google Authenticator keys, this is unfortunately not the case as the QR codes used to create these initial TOTP factors are the seed values and will be the same across all synced devices. Yet another reason to leverage Authy as a 2FA provider.
If you take anything away from this blog post, let it be this:
- Consistent with standard industry practices, all encryption and decryption for both initialization or restoration of backup keys, happens on your device, not in the cloud.
If you have any questions please contact us at [email protected]