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 thei

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.