Hacker News Reader

Comment by danielpal | Hacker News Reader

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.

View on HN

This tweet indicates you're using TOTP, slightly modified from Google's implementation:

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.

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.

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?

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?).

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.

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.

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.

"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.

Reply on news.ycombinator.com