Authy is joining Twilio(authy.com)
authy.com
Authy is joining Twilio
https://www.authy.com/twilio
72 comments
Founder of @Authy here. Happy to answer any questions.
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.
This is not in the spirit of 2FA.
This is not in the spirit of 2FA.
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
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.
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.
This tweet indicates you're using TOTP, slightly modified from Google's implementation:
https://twitter.com/authy/status/498244613766139904
https://twitter.com/authy/status/498244613766139904
@benmcginnes Yes we are RFC 6238 TOTP compatible.
Same algorithm as GAuth but 7 digits, 256 bit keys and 10 seconds window.
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.
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.
Then why not allow users to defer entering a phone number until they try to add a service that actually requires it?
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?).
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?).
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?
[1] https://github.com/nathforge/pyotp
[2] https://github.com/mdp/rotp
[3] http://delyan.me/securing-ssh-with-totp/
[4] https://github.com/mtigas/django-twofactor
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?
[1] https://github.com/nathforge/pyotp
[2] https://github.com/mdp/rotp
[3] http://delyan.me/securing-ssh-with-totp/
[4] https://github.com/mtigas/django-twofactor
Oh thanks for mentioning [4], I always thought 2FA using PAM disabled the key-based authentication and used passwords.
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.
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.
You print off a list of backup codes and stick them in a safe. Then log in with the backup code, and set up a new Authenticator token.
You could also add a U2F token and store that away.
You could also add a U2F token and store that away.
Or save the token in an encrypted password manager so you can retrieve it later
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?!).
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?!).
"identity" isn't part of the 2FA concept (nor should it be)--you're shoehorning in something that doesn't belong.
> 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.
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.
The advantage is that if you lose/switch phones, you don't have to reset your 2FA. (a disadvantage, of course, if your account/device is compromised)
What was the acquisition price ?
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.
Hi, very likely. We will be investing a lot more resources into Authy - Windows Phone App is very high at the top of things we are thinking of doing.
It's just TOTP, so if they weren't creating a walled 2FA garden you could use any of the available TOTP apps on Windows Phone, but alas...
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.
What is the reason for all of these 2FA apps? This is completely unnecessary. If you're going to offer 2FA, please offer at least the following:
* TOTP
* Yubikey
* SMS
* Authy
* RSA
* etc
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
Then why do they need an account or my phone number to do TOTP?
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.
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.
[deleted]
[deleted]
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.
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.
What makes Yubikey part of the "default" set but not Authy or RSA?
This seems awfully like "If you're going to offer 2FA, at least offer all the tools I like, before you offer any tools that I don't like".
It's also worth noting that Authy's app supports TOTP, last I looked.
This seems awfully like "If you're going to offer 2FA, at least offer all the tools I like, before you offer any tools that I don't like".
It's also worth noting that Authy's app supports TOTP, last I looked.
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.
s/Yubikey/U2F/
(But I will use my Yubikey for U2F)
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.
(But I will use my Yubikey for U2F)
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.
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.
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.
[deleted]
[deleted]
Can anyone with experience give an estimate of the acquisition price?
> "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.
Perhaps there's hope in somebody else taking over. Please, Twilio: prioritize _usability_.
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.
Perhaps there's hope in somebody else taking over. Please, Twilio: prioritize _usability_.
On Android, it's attractive, functional, and lets me quickly switch between services. I'm not sure what it could do better.
FWIW, I have 4 services set up on it.
FWIW, I have 4 services set up on it.
It's great with four services.
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.
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.
Current screenshot http://i.imgur.com/EzNc2g9.jpg
Current screenshot http://i.imgur.com/EzNc2g9.jpg
[deleted]
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.
When I open Authy I have a button on the top that toggles from a large text list view and the large icon view.
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?
Exactly why I made GAuthify.com, simple non-proprietary 2fa.
Has anyone gotten the Bluetooth stuff to work on OS X? I tried hard, but never managed to.
To be fair, Bluetooth pairing between iOS and OS X hasn't been the most pleasant experience in general.
--
Authy is a fine app, but the main selling point to me has basically always been the typical "anything but Google's half-abandoned BS".
To be fair, Bluetooth pairing between iOS and OS X hasn't been the most pleasant experience in general.
--
Authy is a fine app, but the main selling point to me has basically always been the typical "anything but Google's half-abandoned BS".
I tried and it only worked if I had the app open on the phone at the time. I don't think I disabled anything like background app refresh.
It's been deprecated in favor of a chrome plugin.. Which alone sux for FF users like myself..
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 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.
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.
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.
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.
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.
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.
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.
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.
You spelt "was acqui-hired by" wrong