4 ms·

Not at all. The attacker would need to get the encryption key and also access to the Authy Backup. Then they also need the password for your account. That said,

Not at all. The attacker would need to get the encryption key and also access to the Authy Backup. Then they also need the password for your account. That said, backups are optional, you can skip them and your account will remain on your phone only.

scottmp10 14y ago
No they don't need the encryption key just like you don't if you get a new phone. They just need to know your password, send it to Authy, and Authy will decrypt the backup and send it to them. Edit: I can't reply to the comments on this but they contain the exact procedure an attacker would have to go through, which, if correct, is much more difficult than just knowing the password.
- danielpal 14y ago
  That's not at all how backups work. In order for a hacker to download the and decrypt the account they would need to: 1. Access to your e-mail to click a link confirming you changed your cellphone. 2. Access to your phone # to be able to get the SMS message with the registration key. 3. The encryption key you used. If they can do all 3 they would get access to your account. If you feel that the level of security there is not good enough for you, you can disable the backups and key will never ever leave your phone
  - X-Istence 14y ago
    I like how there is a nice catch-22 there ... I may need access to my OTP to gain access to 1, yet I need access to 1 to get access to my OTP.
Firehed 14y ago
How are you encrypting the backups? You recommend a passcode of at least 8 characters, which is only 64 bits. Are you at least running it through some sort of key strengthening algorithm like PBKDF2 to generate the actual encryption key?
- danielpal 14y ago
  We're not using PBKDF2. Were using AES-256, we pad the extra bits and use a random IV for each account. However you can enter a 32 character encryption key and you will get a full 256 bit key for encryption.
  - blake8086 14y ago
    You know those aren't even the same kind of thing, right?
  - Firehed 14y ago
    Ok, please don't take this the wrong way, but you guys don't seem to know enough about security to be running this kind of service. Being able to access your MFA token from multiple devices defeats the purpose of it being a second factor (since it's must exist only in a single place to be "something you have"), and now you're recommending a backup passcode with less security than WPA2 - a passcode to a backup that by definition should not be allowed to exist. It's bad enough that Google's TOTP keys are too short (80 bits, below the required 128 and recommended 160+), especially given the clarity of the spec and the size of their organization, nevermind being the first large-scale rollout. It's also unfortunate that they half-assed their Authenticator app, which hasn't seen an update in over two years. At least they've had the good sense to improve the workflow of regenerating a token for a new device. I appreciate the problem you're trying to solve and am aware that there tends to be a lot of headache in additional security, but doing this kind of thing provides a false sense of security if not outright lowering the security of what already existed. If I can get access to my MFA tokens by typing in a password, then it's a knowledge factor and not a possession factor. That's one-factor auth with two passwords, like the "security" questions on many banks.
    - danielpal 14y ago
      We were limited by Google Authenticator usage, so yes, backups are absolutely awful, but it was the only way we saw fit in case you had to upgrade/lost your phone. Now our service Authy and it's Tokens are completely different. If you sign-up to Authy.com and use our Tokens, those are: 1. Full 256 bits secret seeds. 2. They are never backed-up. 3. Guaranteed to only exist on 1 phone at any given time. 4. We not only regenerate new tokens for new device, we also allow 1 click remote reset of the device tokens. 5. We have a huge number of improvements over Google Authenticator. 7. Tokens are not 6 but 7 digits long. This version added support for legacy Authenticator Tokens. The existing Authy tokens like CloudFlare, DNSimple etc are not limited to the Google Authenticator addon.

scottmp10 14y ago

No they don't need the encryption key just like you don't if you get a new phone. They just need to know your password, send it to Authy, and Authy will decrypt the backup and send it to them. Edit: I can't reply to the comments on this but they contain the exact procedure an attacker would have to go through, which, if correct, is much more difficult than just knowing the password.

danielpal 14y ago
That's not at all how backups work. In order for a hacker to download the and decrypt the account they would need to: 1. Access to your e-mail to click a link confirming you changed your cellphone. 2. Access to your phone # to be able to get the SMS message with the registration key. 3. The encryption key you used. If they can do all 3 they would get access to your account. If you feel that the level of security there is not good enough for you, you can disable the backups and key will never ever leave your phone
- X-Istence 14y ago
  I like how there is a nice catch-22 there ... I may need access to my OTP to gain access to 1, yet I need access to 1 to get access to my OTP.

Firehed 14y ago

How are you encrypting the backups? You recommend a passcode of at least 8 characters, which is only 64 bits. Are you at least running it through some sort of key strengthening algorithm like PBKDF2 to generate the actual encryption key?

danielpal 14y ago
We're not using PBKDF2. Were using AES-256, we pad the extra bits and use a random IV for each account. However you can enter a 32 character encryption key and you will get a full 256 bit key for encryption.
- blake8086 14y ago
  You know those aren't even the same kind of thing, right?
- Firehed 14y ago
  Ok, please don't take this the wrong way, but you guys don't seem to know enough about security to be running this kind of service. Being able to access your MFA token from multiple devices defeats the purpose of it being a second factor (since it's must exist only in a single place to be "something you have"), and now you're recommending a backup passcode with less security than WPA2 - a passcode to a backup that by definition should not be allowed to exist. It's bad enough that Google's TOTP keys are too short (80 bits, below the required 128 and recommended 160+), especially given the clarity of the spec and the size of their organization, nevermind being the first large-scale rollout. It's also unfortunate that they half-assed their Authenticator app, which hasn't seen an update in over two years. At least they've had the good sense to improve the workflow of regenerating a token for a new device. I appreciate the problem you're trying to solve and am aware that there tends to be a lot of headache in additional security, but doing this kind of thing provides a false sense of security if not outright lowering the security of what already existed. If I can get access to my MFA tokens by typing in a password, then it's a knowledge factor and not a possession factor. That's one-factor auth with two passwords, like the "security" questions on many banks.
  - danielpal 14y ago
    We were limited by Google Authenticator usage, so yes, backups are absolutely awful, but it was the only way we saw fit in case you had to upgrade/lost your phone. Now our service Authy and it's Tokens are completely different. If you sign-up to Authy.com and use our Tokens, those are: 1. Full 256 bits secret seeds. 2. They are never backed-up. 3. Guaranteed to only exist on 1 phone at any given time. 4. We not only regenerate new tokens for new device, we also allow 1 click remote reset of the device tokens. 5. We have a huge number of improvements over Google Authenticator. 7. Tokens are not 6 but 7 digits long. This version added support for legacy Authenticator Tokens. The existing Authy tokens like CloudFlare, DNSimple etc are not limited to the Google Authenticator addon.