Lots of hostility toward Authy on here, I'm shocked. I'm an Authy user and I've always liked the service in that I've barely noticed it existed. Super glad to use 1 app for most services I have 2FA on.
Yeah, my sentiment on this acquisition is "one company I like/use buying another company I like/use, I hope it goes well".
I switched to Authy when Google Auth 'forgot' all my tokens in one of its updates (which ended up being restored later), and Authy has worked flawlessly since then.
Interesting acquisition, glad to see authy as a service living in Twilio instead of just using it. Can't wait to see it in the portal. Make sure you read Jeff's post as well.
Why do you refuse to delete accounts? It is my data and I want it to be removed. How can I feel safe about my data if I cannot remove it if I choose not to continue using your service.
Why does Authy require I provide my cell phone number and email address? Why do I have to have a user account? This is completely ridiculous. I do not need nor want cloud syncing or backup. You are making Authy a potential target for attacks by associating a user to cloud stored 2FA information.
An in my opinion crucial information is missing in the discussion that unfolded here 4 years ago; still this discussions comes up as a top result when searching for "authy telephone number required" and that is why I want to add something for current and future references:
The phone number is only needed to recover access to your encrypted data that is stored on authys servers.
If you're questioning yourself whether authy is trustworthy because they require you to provide a phone number for a 2FA-TOTP-Method that does technically not require it at all(!) and thus could pose a potential security degredation, check the FAQ about account recovery/passwords here: https://support.authy.com/hc/en-us/articles/115001950787-Bac...
Quote:
* The Backups password is never sent nor stored in our servers for your security
* Like the Backups password, the App Protection PIN (and optional biometric data) is never stored in our servers
* Like the Backups password and App Protection PIN, the Master Password is never stored in our servers
the question still is if you trust those promises - but as authy is backed by twilio (thus lots of 2FA-SMS are already processed by them) the chances are good those guys know what they do and do it responsibly
Hi, good question. The reason for the phone number is that we depend on your phone number as part of your identity. Almost all 2-FA systems today use the phone number as a way to send you the code via text/phone call. If you read my blog post: blog.authy.com/twilio you'll see we decided to build our infrastructure on top of the telecom infrastructure because it was ubiquitous.
I also understand why some people don't like clouds backups. The good news is that backups are off by default and optional. If you don't need them, you can keep them disabled.
@benmcginnes Yes we are RFC 6238 TOTP compatible.
Same algorithm as GAuth but 7 digits, 256 bit keys and 10 seconds window.
So why do you still need my phone number? There's no network connection or SMS required to generate those TOTP codes. I'm not buying the story that you need to text me or call me unless you're storing the seed/token centrally and sending it to users upon request which I strongly disagree with. That should only be stored on the user's device.
For those interested in how TOTP is implemented, here it is in Python [1] and Ruby [2]. It is really simple and understandable. Oh, and did you know you can secure your SSH connections using TOTP [3]?
This stuff is no more complicated than storing password hashes. Having a nice client app is good, but Google Authenticator is good enough. So instead of using authy and relying on a third party, why not get something like [4] and be done with it?
Authy exists to make 2 factor easier for people implementing it. Some users will want methods other than TOTP, so they support methods other than TOTP.
If they don't have a phone number they can't do all that transparently, which is bad when you are aiming your service at a broad audience.
Because doing a high enough level of identity verification at that point would be disruptive.
I'm not really interested in defending it, I probably don't like the idea of depending on a third party any more than feld does, I was just pointing out that there are simpler explanations for what they are doing than I'm not buying the story that you need to text me or call me unless you're storing the seed/token centrally and sending it to users upon request which I strongly disagree with.
Another one is that if they actually implemented TOTP like that their business would take a lot of damage when it was revealed publicly (because what's the point of paying for a broken implementation?).
Ok, serious question: how do you manage your tokens? What happens if your device flies out of the window?
A couple of months ago I managed to break the screen of my tablet with 20-30 services I use 2FA (Google Authenticator). I had to spend about 50 bucks just to get a new screen and repair it.
For some of these services I had the token saved on my keepass, but I always felt a little dirty doing that. If there was a way to keep backups of Google Authenticator data, I'd take it in a heartbeat.
Not all of the services that implement Google's 2FA provide backup codes. Plus, the idea is that 2FA should be used anywhere, even for lesser-values web sites, so the idea of printing everything seems to be archaic.
Is that method of sending the Authy authentication code any more secure than all the "regular" SMS-based 2FA methods (like say Gmail's SMS-based 2FA)? If so, how?
I think Google's (or Microsoft's because I think they use a similar SMS-based 2FA) method could be easily manipulated by intelligence agencies for example with access to the carriers' networks. The Google Authenticator app is now completely useless for Gmail as well, since they made it to fallback to SMS-based 2FA if you forgot your password (ugh - why Google? WHY?!).
> we decided to build our infrastructure on top of the telecom infrastructure because it was ubiquitous.
I am not very familiar with Authy, but I have built pin-code 2FA solutions using Twilio. Based on your comments, I am not sure the point of Authy if it is easy to build 2FA except TOTP using yesterday's Twilio.
Hi An6n, Fido and U2F are really interesting to us - we are totally supportive of it and have some really great things planned around this area. Stay tuned!
Do you have any plans for a Windows Phone app? The SMS backup works well, but an app would be ideal; it's one of the few things I'm still missing after switching from Android.
When I first tried Authy, I was amused by bluetooth sync for OTPs. Then, when I tried hardware TSV like yubikeys, I realized that Authy was only a marginal improvement in technology, while it would take a complete rethinking of the system - e.g. Yubikey - to scale to dozens of accounts, multiple devices, and corporate adoption.
I stopped using Authy a few weeks ago after I upgraded phones and lost access to all the tokens I had on my own phone.
Perhaps I should have read the instructions more carefully, perhaps I am an idiot. But I thought the purpose of an app linked to my cell phone number is that these codes would port automatically.
As a result, I will never use Authy again.
SMS validation seems to work fine, which is good business for Twilio. Not sure I understand the acquisition, unless Authy has some good math in their code generation process.
In my experience, Authy does port your OTP tokens between devices.
The ones that use their backend infrastructure are tied to your phone number, and are ported automatically.
Ones that you import from other TOTP-based systems via a QR code (like Google Authenticator) are private to your device by default. But if you really want, you can turn on the optional "backup" feature in settings, which will upload them to your Authy account and automatically port them between phones.
Sure, it requires an extra step... but to be fair, normal behavior for TOTP codes is to keep them 100% local to the device. I'd argue this is a reasonable default, given that security is involved. TOTP services almost always require a backup method (SMS or scratch codes) in case you switch phones, anyway.
> "There are few companies who share our dedication to excellence…"
Authy is one of the worst-designed iOS applications I have ever used. It has been this way for a very long time. They are actively hostile to people who try to criticize their poor design choices. I would not classify it as "dedicated to excellence."
CloudFlare forces me to keep it installed, so I have to interact with it on occasion. If you have more than about 3 services set up, you have to first scroll to expand the scrolling list of icons, then scroll multiple times to find and read the 10pt font name of a service, etc. It's awful. Compare it to Google Authenticator, which has a nice, big scrolling list of numbers and names. The one advantage Authy has is encrypted backup, which I like, and service lock-in, which annoys me.
It's awful with dozens. I, for example, have four client AWS accounts, each with the AWS icon, that are rather difficult to distinguish between. The earlier iOS app (with a left-hand side drawer and larger text) was much better for me.
Have you not updated in a while? For me it works fine. I see all the icons for all of my services all the time. Click the one I want and get the number. No Scrolling required.
If you use many services, often with the same company (say multiple Google accounts) it doesn't look that clean; you have many repeating icons. Many of which, you'll get a generic key (if only they'd let me add a custom icon). Then you're stuck with reading that tiny font, which requires several seconds of scanning, even on a 6 Plus.
There seems to be two types of people here who like/dislike it. With few services they love the new design, and with a lot they hate it. The Android app was also updated to the square icons on the bottom, the drawer was much better if you had a lot of services added.
No it just doesn't work. It is still available on the Mac App Store and when I contacted them on Twitter they said "oh, we will look into the problem you are having" but at the same time their website says it says the OSX app is discontinued due to bugs in OSX Bluetooth driver https://authy.zendesk.com/hc/en-us/articles/202760296-Having...
I would not trust such liars with credentials to my most important services.
I use the MAS version of the Authy BT app. It pairs correctly about 90% of the time. The remaining 10% it refuses to pair up, even with the iOS app open, but I'm pretty sure that's Apple's buggy BT drivers, not Authy. That 10% failure is a minor annoyance, but (90% of the time) the convenience of being able to easily paste codes into my browser already make the UX much better than Google Authenticator.
It used to be bad, but at least on iOS they are reasonably good now, I've never felt this way. and I am not very easy to please. Which app are you talking about?
What's your issue with Authy's UI? I switched to Authy from Google Authenticator because I didn't like its boring UI. Authy is a lot easier to use, from my perspective anyway.
Because Yubikey is very reasonably priced and they're very open about their design... and don't require you provide any identifying information to own one.
Well, except, you have to buy one from somewhere, and I believe they are only officially being sold through their own site or Amazon. So you are providing your identifying information to some party before even getting the device.
You do realise that with authy you're just registering TOTP stuff right? It's not on the same level as what you're mentioning. It's like complaining about having to use Firefox instead of google.com
Because Cloudflare requires Authy, not TOTP. It's a pain in my ass because Cloudflare doesn't have sub-accounts and I have more than one person managing a Cloudflare account, but Authy is locked to one device. So as a result I can't turn on two-factor on my Cloudflare account.
Yes, that's definitely unfortunate. I don't remember it being required with older versions of the Authy app. I really hate forced cloud service integration, especially in applications that deal with sensitive material.
they don't, but they want to have a way to verify who you are for things like the sync feature. Even if you don't want to use the feature.
This is a pretty good example of not doing something because it represents a minority and would make onboarding more difficult for their actual value-add.
I don't understand this rage. I've used Authy with regular TOTP services, and in some cases where I was explicitly told to use something else like Google Authenticator. Unless this changes, I don't see any reason to stop using Authy.
I also refuse to install Authy. I really, really do not like their creeping, creepy intrusiveness and the profiling it enables. I get the feeling that people don't actually understand Authy beyond "Hey, it backs up my secrets to the cloud. Cool!"
I recently had to renew my Google Authenticator tokens and I was tempted by Authy but the setup/onboarding sent me away screaming. Then I remembered the NEO can handle this (well except for Amazon tokens). Can't wait for U2F NFC to be standardized.
This precisely. I commend Authy for trying to make 2FA for a wide audience, but security is not easy. Training users is the correct approach.
Give an option for those who deeply care about their security. If you're going to grab the industry by the balls and capture the attention of major industry players at least stick to your core values and offer an advanced/expert option for those of us who want to stay out of your system but still use 2FA.
