Hacker News Reader

Comment by feld | Hacker News Reader

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.

View on HN

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?

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.

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.

Reply on news.ycombinator.com