I am a big fan of two-factor authentication. Heck, I even have my own site and C# code to prove it. :)
Let’s just quickly recap most common two-factor authentication: Beside user name and password your service provider usually has, you have additional private key shared between you. Based on that key, current time, and some clever crypto (also known as TOTP) you will get new 6-digit code every 30 seconds. Whenever additional security is needed (e.g. login from a new computer) you enter that code and server checks it against its own calculation. Since entered code depends on a key that is never transmitted over the network and it changes all the time, chances of somebody faking your account regardless of snooping traffic and knowing your user name and password are significantly lowered.
While all this is not panacea, for me it is clear: If some service has option of two-factor authentication, you can pretty much be sure I’m going to use it. Except for CloudFlare. Why? Because CloudFlare decided to go with Authy.
Major beef I have is that, while I trust CloudFlare, that trust does not extend to all their partners. With Authy not only I am giving my phone number but I actually have to trust my (partial) login details to them. By design they have my login e-mail, phone number and token. Only password is missing from the list. While pretty much all other services will allow me to retrieve shared key and use application of my choice with me deciding who I want to trust, with Authy that choice is out of your hands.
If you want to use it with another application you will stumble upon a wall of intentional incompatibility. Where virtually everybody else uses 6-digits with SHA-1, Authy uses SHA-256 and 7 digit codes. Although there are some attacks on SHA-1 algorithm, they do not apply on its HMAC version used with TOTP. In this context SHA-1 is as secure as SHA-256 - no more, no less. Seven digit code does give slightly increased security but not a significant one. It pretty much boils to fact that the only benefit Authy gets from this is user lock-in.
There is at least one 6-digit SHA-1 TOTP client on every platform you can think of. From Linux command line to a Pebble watch. You can have your code generated wherever you want. Not so with Authy - it only supports iPhone, Android, BlackBerry and Chrome. Forget about native Windows or OS X application.
Yes, Authy can import other keys (e.g. Google’s), largely helped by the fact that all other TOTP services use exactly same process Authy intentionally avoids. If you do that you get a benefit of syncing all your tokens across all your devices. Think about that for a moment. For that to work Authy has to store them centrally. Can you really ignore fact that Authy suddenly has access to tokens for all services you hold dear and that some SSL bug might cause their exposal? I prefer not to even think what damage rogue employee might do.
In some regards I appreciate proprietary services like VIP Access more - while they are not cooperating with other applications and are fracturing auth universe, at least they are not trying to steal all your other tokens. While intentions might be the best, Authy is doing just that - stealing all you tokens by a false pretense it can keep that data secure.
Among all the crazy stuff, only saving grace for Authy is ability to PIN protect mobile application. Considering all other nonsense Authy brings, I don’t think it’s worth it - just practice locking your phone.
All this is not really Authy’s fault. They have their business case whether they continue to provide API for two-factor authentication or if they decide to run with all collected data. I am disappointed with CloudFlare for their lousy job in analyzing what users want. Although they did go through motions, their conclusions don’t make sense. Let me give you a few examples:
Although they kick out Google Authenticator platform from their consideration, they end up deciding on essentially same system with Authy - both Google and Authy system rely on standardized TOTP cryptography. There is essentially no difference between them - other than Google having open-source solution and Authy being closed-source. And bug they mention had nothing to do with cryptography anyhow.
Then they mention Authy’s ability to revoke keys as a huge advantage. Compared to others Authy’s system is just over engineered with having separate private/public and token keys. All other systems don’t offer easy revoke functionality because they don’t have to - just generate a new key instead of the old one and you have exactly the same effect because all codes generated with the old key won’t match. All Authy offers here is a dialog box toward customer explaining that key is revoked. At most this is GUI benefit, not a security one.
Lastly they state that TOTP requires “fairly precise match” of the user’s clock for authentication to work. How do you define fairly precise? In RFC itself it is recommended to allow for at least 30 seconds difference (up to 89 seconds). Even if we assume you have valid reason why some of your clocks might be more than 30 seconds off, do you wonder how Authy accomplishes better reliability than others? Only way they can do that is if they accept code for longer and essentially make more codes valid. There is a reason why 30 seconds was selected as a step and why acceptable window is recommended to be within 60 seconds and not e.g. 20 days.
It might just be me, but I think CloudFlare made a bad choice and I won’t be having it.
PS: Gem from Authy’s privacy policy: “If Authy is involved in a merger, acquisition or asset sale, we might not continue to ensure the confidentiality of any personal information nor give affected users notice before personal information is transferred or becomes subject to a different privacy policy.” Honest and worrisome.
PPS: Yes, screenshot is real: iPhone application seems to have a bug where certain private keys that work just fine on Android and Chrome will cause output to be 000000.
