5 ms·

So I can install just the Google app and enter my Authy codes there, and vice versa?

by omh 14y ago

jgrahamc 14y ago
My understanding is that Authy uses a key that is twice the length of the Google Authenticator key and so they are not compatible. Also, there are other things that Authy does way better than Google Authenticator: 1. If you change phones you have to reconfigure all your accounts that are using Google Authenticator. With Authy it just works when you install the Authy app on the new phone. 2. Authy fixes time sync problems between your phone and UTC in the background so you do not have to worry. 3. And if you lose your phone with Google Authenticator there's no simple way to revoke access to all your accounts. With Authy there is. 4. Authy has a way to revoke tokens across all devices. If (like what happened to RSA) the private information were stolen from Authy they can invalidate all the tokens and securely reissue new ones.
- marshray 14y ago
  According to https://www.authy.com/help/faq https://www.authy.com/help/faq, it looks like they're using http://tools.ietf.org/html/rfc4226 http://tools.ietf.org/html/rfc4226 HOTP with some version of SHA-2 and a 256 bit seed. The suggested default for HOTP/TOTP is SHA-1 with a 160 bit seed and that's what most systems seem to use.
- rdl 14y ago
  #1 is the biggest problem with Google Authenticator today (as well as inconsistent use of Authenticator across various Google properties, but that wouldn't matter to a third party site). AWS supports the same system in a less brain-dead way, treating the authentication as a separate feature per account profile, and letting you re-enroll a new token and delete the old one. I'm pretty sure this is a Google Account problem, not a Google Authenticator problem. (AWS IAM is actually a pretty awesome product, but not very well documented, and from what I've seen of AWS users, not being correctly used to even 5% of its potential by most users.) It's obviously more secure to make changes to the authentication system harder than just "any single valid login from any device lets me reset authentication requirements for future logins", though. The real problem is being able to get a one-time authenticated login, use that session to add a new "always let me log in" credential, and leave everything else as-is. The legitimate owner then has no reason to be suspicious, and you can continue to subversively use the account. It's almost better when the legit owner is forced out of his account on a change like that, as he can then contact Google's excellent customer support (...) to resolve the issue. Of course, Google exposes themselves to THAT with application specific passwords, which are neither application-specific nor otherwise limited, and can be created easily once you log in.
  - harshreality 14y ago
    I'd rather deal with resetting OATH 2-factor tokens, than rely on proprietary apps like duo or authy, or rely on the security of mobile networks (for SMS). That complication is an unavoidable consequence of not relying on trusted third parties (like authy or duo), right? Apps like those also encourage fracturing of the 2-factor ecosystem, rather than relying on a single standard. I realize that corporations with lots of employees to support see things differently, and centralized 2-factor proxy in that environment makes more sense. The only problem I have with google authenticator is that it's barely maintained. Even obvious features like rearranging order of accounts, haven't been implemented. http://code.google.com/p/google-authenticator/issues/list?can=2&q=&sort=-stars http://code.google.com/p/google-authenticator/issues/list?ca... Although they could add some export functionality, that would be a problem, now that I think about it, because anyone with even brief access to your phone could export all the OATH seeds to their phone.
    - stock_toaster 14y ago
      > The only problem I have with google authenticator is that it's barely maintained. Even obvious features like rearranging order of accounts, haven't been implemented. http://code.google.com/p/google-authenticator/issues/list?ca.. http://code.google.com/p/google-authenticator/issues/list?ca.... There is also a weird bug in google authenticator (on ios) where the edit button in the lower left doesn't work until you hit legal information button, then go back. Very weird.
      - rdl 14y ago
        Actually Google seems to have fixed the one issue I really cared about; it's possible to create a new device (and then manually use the new code to put the app on both iPhone and iPad) without turning off 2-factor-auth entirely. But they don't actually check that you have the 2 factor device when you do this, so all you need to do is get logged in once and you're clear to lock the original user out, change auth credentials, etc. It's totally fine for the "protect a personal gmail account" threat model, but as far as I can tell, no one does 2fa in a way as-secure as I'd want it for an enterprise/IT deployment.
- Firehed 14y ago
  re: key length - Google Authenticator supports any length of key; Google happens to provide 80-bit (below the 128-bit minimum, per the HOTP spec!) keys for their own services. However, it does NOT support > 6 character output length, nor HMAC algorithm, nor (for TOTP) varying step or offset support. re: 1 - By putting your MFA codes in a centralized (and synchronizable) location, you're losing much of the effectiveness of the second factor. So "when you install the Authy app on the new phone" now there are two (or more) devices with access to the second factor. So when someone hacks your Authy account, all of your MFA tokens are compromised. re: 2 - time sync problems are supposed to happen server-side, per the spec. As an implementor it's nice to not have to solve that problem, but you should be using a library for it regardless. Also, please find me a phone (at least one with GPS) that doesn't keep remarkably accurate time. I'd be more worried about server clock drift. re: 4 - Any company dealing with MFA secret keys should have a way to revoke them. It's conceptually as easy as nulling out a cell in a database. By putting everything with this service provider, you're increasing the amount of damage a single breach can do. There are a lot of things wrong with Google's Authenticator app, but the fact that it doesn't sync with a remote service is a HUGE benefit to security. I like the idea of a "revoke everything from this device" button, but I don't like having all my security eggs in one basket.
  - stock_toaster 14y ago
    > There are a lot of things wrong with Google's Authenticator app, but the fact that it doesn't sync with a remote service is a HUGE benefit to security. I like the idea of a "revoke everything from this device" button, but I don't like having all my security eggs in one basket. I strongly agree.

So I can install just the Google app and enter my Authy codes there, and vice versa?

by omh 14y ago

So I can install just the Google app and enter my Authy codes there, and vice versa?

My understanding is that Authy uses a key that is twice the length of the Google Authenticator key and so they are not compatible. Also, there are other things that Authy does way better than Google Authenticator: 1. If you change phones you have to reconfigure all your accounts that are using Google Authenticator. With Authy it just works when you install the Authy app on the new phone. 2. Authy fixes time sync problems between your phone and UTC in the background so you do not have to worry. 3. And if you lose your phone with Google Authenticator there's no simple way to revoke access to all your accounts. With Authy there is. 4. Authy has a way to revoke tokens across all devices. If (like what happened to RSA) the private information were stolen from Authy they can invalidate all the tokens and securely reissue new ones.

marshray 14y ago
According to https://www.authy.com/help/faq https://www.authy.com/help/faq, it looks like they're using http://tools.ietf.org/html/rfc4226 http://tools.ietf.org/html/rfc4226 HOTP with some version of SHA-2 and a 256 bit seed. The suggested default for HOTP/TOTP is SHA-1 with a 160 bit seed and that's what most systems seem to use.
rdl 14y ago
#1 is the biggest problem with Google Authenticator today (as well as inconsistent use of Authenticator across various Google properties, but that wouldn't matter to a third party site). AWS supports the same system in a less brain-dead way, treating the authentication as a separate feature per account profile, and letting you re-enroll a new token and delete the old one. I'm pretty sure this is a Google Account problem, not a Google Authenticator problem. (AWS IAM is actually a pretty awesome product, but not very well documented, and from what I've seen of AWS users, not being correctly used to even 5% of its potential by most users.) It's obviously more secure to make changes to the authentication system harder than just "any single valid login from any device lets me reset authentication requirements for future logins", though. The real problem is being able to get a one-time authenticated login, use that session to add a new "always let me log in" credential, and leave everything else as-is. The legitimate owner then has no reason to be suspicious, and you can continue to subversively use the account. It's almost better when the legit owner is forced out of his account on a change like that, as he can then contact Google's excellent customer support (...) to resolve the issue. Of course, Google exposes themselves to THAT with application specific passwords, which are neither application-specific nor otherwise limited, and can be created easily once you log in.
- harshreality 14y ago
  I'd rather deal with resetting OATH 2-factor tokens, than rely on proprietary apps like duo or authy, or rely on the security of mobile networks (for SMS). That complication is an unavoidable consequence of not relying on trusted third parties (like authy or duo), right? Apps like those also encourage fracturing of the 2-factor ecosystem, rather than relying on a single standard. I realize that corporations with lots of employees to support see things differently, and centralized 2-factor proxy in that environment makes more sense. The only problem I have with google authenticator is that it's barely maintained. Even obvious features like rearranging order of accounts, haven't been implemented. http://code.google.com/p/google-authenticator/issues/list?can=2&q=&sort=-stars http://code.google.com/p/google-authenticator/issues/list?ca... Although they could add some export functionality, that would be a problem, now that I think about it, because anyone with even brief access to your phone could export all the OATH seeds to their phone.
  - stock_toaster 14y ago
    > The only problem I have with google authenticator is that it's barely maintained. Even obvious features like rearranging order of accounts, haven't been implemented. http://code.google.com/p/google-authenticator/issues/list?ca.. http://code.google.com/p/google-authenticator/issues/list?ca.... There is also a weird bug in google authenticator (on ios) where the edit button in the lower left doesn't work until you hit legal information button, then go back. Very weird.
    - rdl 14y ago
      Actually Google seems to have fixed the one issue I really cared about; it's possible to create a new device (and then manually use the new code to put the app on both iPhone and iPad) without turning off 2-factor-auth entirely. But they don't actually check that you have the 2 factor device when you do this, so all you need to do is get logged in once and you're clear to lock the original user out, change auth credentials, etc. It's totally fine for the "protect a personal gmail account" threat model, but as far as I can tell, no one does 2fa in a way as-secure as I'd want it for an enterprise/IT deployment.
Firehed 14y ago
re: key length - Google Authenticator supports any length of key; Google happens to provide 80-bit (below the 128-bit minimum, per the HOTP spec!) keys for their own services. However, it does NOT support > 6 character output length, nor HMAC algorithm, nor (for TOTP) varying step or offset support. re: 1 - By putting your MFA codes in a centralized (and synchronizable) location, you're losing much of the effectiveness of the second factor. So "when you install the Authy app on the new phone" now there are two (or more) devices with access to the second factor. So when someone hacks your Authy account, all of your MFA tokens are compromised. re: 2 - time sync problems are supposed to happen server-side, per the spec. As an implementor it's nice to not have to solve that problem, but you should be using a library for it regardless. Also, please find me a phone (at least one with GPS) that doesn't keep remarkably accurate time. I'd be more worried about server clock drift. re: 4 - Any company dealing with MFA secret keys should have a way to revoke them. It's conceptually as easy as nulling out a cell in a database. By putting everything with this service provider, you're increasing the amount of damage a single breach can do. There are a lot of things wrong with Google's Authenticator app, but the fact that it doesn't sync with a remote service is a HUGE benefit to security. I like the idea of a "revoke everything from this device" button, but I don't like having all my security eggs in one basket.
- stock_toaster 14y ago
  > There are a lot of things wrong with Google's Authenticator app, but the fact that it doesn't sync with a remote service is a HUGE benefit to security. I like the idea of a "revoke everything from this device" button, but I don't like having all my security eggs in one basket. I strongly agree.