I've been trying out Authy, a Google Authenticator alternative with an optional feature of being able to back up your tokens. They have two types of tokens: Authy-generated tokens and the regular OTP tokens you added by scanning a QR code (like you would in Google Authenticator).

If I understand correctly, backups of your standard OTP tokens are encrypted with a password before uploading them to Authy. Your backup password isn't sent to their servers, they just store an encrypted blob of data for you. Sounds good so far.

However, when setting up Authy on a new device I noticed that the Authy-generated tokens don't seem to benefit from the same level of security. When you set up Authy on a new computer you can get access to your account through SMS verification (something they've criticized for being insecure). Entering an SMS passcode will log you in and give you immediate access to your Authy-generated tokens (assuming you've enabled multidevice support). The Authenticator tokens are still encrypted at this point, and they can be decrypted if you enter the backup password.

What are the security implications of this? Doesn't the SMS-based login procedure make Authy-generated tokens quite vulnerable to capture?

  • 1
    Awesome question, calling Authy out on critiziting certain practices, then offering them as options! I'm not an Authy user, but it sure sounds like it's possible to significantly weaken your account via the options they provide -- a false sense of security for end users? Commented Sep 1, 2018 at 19:31

1 Answer 1


Let us review the threat: MiTM - SS7 attack to retrieve the SMS for Authy. If that scenario happens, the attacker will have a grasp over your encrypted tokens meaning that the attacker needs the password (or a flaw in the encryption algorithm, which is less likely since they use industry-standard algorithms) in order to decrypt them.

In such a case, the password complexity will determine how long it would take to recover to tokens.
However, I agree that they could have enhanced their authentication mechanism (using an additional user/password, secret of a sort) as in the current method, it is easy to abuse SS7 to get the encrypted tokens and perhaps parallelize the brute-force process.

  • 1
    There are two categories of tokens though, as shown in this screenshot. I did not need to enter a password to decrypt the ones under 'Authy accounts'. I did need a password to decrypt the ones under 'Authenticator accounts'.
    – Pieter
    Commented Aug 2, 2018 at 18:23
  • 2
    @Pieter I see. As you can read here: support.authy.com/hc/en-us/articles/…. It depends on the multi device support. If it is enabled than the authorization will be based on the registered phone and the sms. If multi device is not enabled. You need to recover the account in a process that involves the email as well. I'll test this out and see if I can take advantage of the former configuration in order to get the Authy accounts.
    – Harel M
    Commented Aug 2, 2018 at 18:38
  • 2
    So unless I disable multidevice access, an attacker would only need to intercept a verification SMS to access my Authy account tokens?
    – Pieter
    Commented Aug 5, 2018 at 18:49
  • Yes, the attacker must intercept an SMS message from Authy to hack your account. Less than you enable Multi-device Access. Commented Oct 25, 2019 at 10:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .