[pilif]

The issue I have with third-party token applications like the Duo Security one that the github guys are recommending is that due to the way how TOTP works (shared secret), I'm practically giving away my second factor to whoever produces the app.

Google Authenticator has the advantage that it's Open Source, but I can't really control whether the thing I downloaded in the app store is actually built from the public sources. But at least I can build my own if I have a developer account. Apparently people are having issues with GA on iOS7 though (it tends to forget the keys), so now I'm kinda out of luck.

Authy is both closed source and wants my cell phone number, Duo Security is just closed source.

I know it's crazy inconvenient in the long run, but I'd much rather install a github official authenticator app than to trust a third-party app with the github token.

[bpatrianakos]

These are exactly the issues I'm dealing with in re-implementing two-factor auth in my own app. On the one hand you can easily roll your own SMS based TFA with the option to use Google Authenticator with a negligible amount of work. Google's app is pretty reliable and most people trust Google (rightly or wrongly is beside the point here).

But then what if Google pulls the rug out from under apps that rely on it and what if knowledgeable users like you don't like the idea of a third party having access to their second factor?

I'm starting to think that unless you're willing to build your own authenticator apps for multiple mobile OSes SMS-only is the best way to go.

[SEMW]

> But then what if Google pulls the rug out from under apps that rely on it

As has been pointed out, it's open source (specifically, Apache 2.0)[1]. So, fork the code[2], if necessary find&replace any google trademarks, and republish as a dedicated authenticator for your own app. Or use one of the existing apps which have forked off gauthenticator, e.g. https://github.com/kaie/otp-authenticator-android .

[1] Except for some bits specific to gmail's 2-factor workflow added after v2.21

[2] git clone https://code.google.com/p/google-authenticator/

[bri3d]

Why not just support both? As a savvy user I can choose SMS-only without ever letting Google anywhere near my shared secret.

Or I can implement or build from source a TFA app I trust and use that.

I really hate sites that support TFA and don't support authentication apps as I have very poor phone service at both my home and place of work and hence SMS is a frustrating experience for me.

[IgorPartola]

SMS is not a secure channel. For example transmitting patient info over SMS violates HIPPA.

[bri3d]

Wait - I was disagreeing with the GP's assertion that SMS-only was a good idea, so I think we very much agree. Maybe you meant to respond to my parent post?

IMO a shared-secret OTP app is certainly not unbreakable but is more secure than SMS.

SMS is known to be easily subpoenaed and universally stored while believing in a widespread OTP app trojan-horse requires some form of tinfoil-hattery. Both are still orders of magnitude more secure than single-factor authentication anyway and hence I believe both should be included in a reasonable 2-factor authentication solution.

Personally I can't adopt an SMS-only 2-factor solution due to service issues anyway.

[StavrosK]

You don't need a developer account for an Android app. Connect your phone to the pc, press "build" in Eclipse, select the phone and the app's there. You can even just transfer the apk over and install it.

[hahainternet]

Even better, use AIDE on device. You can even just give it a github url and have it build you an APK locally.

[rdl]

I also want to be able to give the site a seed to an existing token, i.e. a hard token like the gemalto. This is the step so many of them get wrong.

(If I'm logging in primarily from a phone/tablet, an authenticator app on the same device is much less secure against targeted attacks than a hardware token would be. Plus, hardware tokens allow lots of useful things like physical-escrow based access control.)

[pilif]

The problem with token reuse is the same as with password reuse: If a site gets compromised, your token is worthless. If the token is burned into hardware, then your hardware is now worthless.

[rdl]

I didn't mean that tokens should be shared across sites; more that a single physical token for a role account (like a backup admin login for an auditor could be escrowed with a CFO (who does not have a login)

You'd still have one hard token per site (in reality, you'd have one or two hard tokens for the most important things, and then use soft tokens for everything else.)

[Rizbo]

Android Token app doesn't require any permissions and is free open source Software. The current version of Google Authenticator isn't open source.

[vulf]

You could just use the SMS option instead of the app one when you turn on github's 2fa. Then no 3rd party will have access to the secret.

[wereHamster]

Except the NSA party...

[andyhmltn]

>Apparently people are having issues with GA on iOS7 though (it tends to forget the keys),

Yep. I opened mine one day and all my keys were gone. It's a real pain.