Comment by danielpal
11 years ago
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.
This tweet indicates you're using TOTP, slightly modified from Google's implementation:
https://twitter.com/authy/status/498244613766139904
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?
[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.
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.
Then why not allow users to defer entering a phone number until they try to add a service that actually requires it?
1 reply →
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.
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.
2 replies →
"identity" isn't part of the 2FA concept (nor should it be)--you're shoehorning in something that doesn't belong.
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.