Hacker News new | past | comments | ask | show | jobs | submit login
Two-factor Authentication (github.com)
267 points by tanoku on Sept 3, 2013 | hide | past | web | favorite | 88 comments

I'd just like to point out that this is another example of the failure of the overly-rigid submission title policy here. This title tells me almost nothing about the content I'm about to see or whether it's relevant to me. Expecting to see something about 2FA in general or maybe even a library that eases implementation (given the github domain), I was let down when I opened the link and realized I didn't care in the least about this content. I wasted my time browsing, and I wasted even more time writing this rant.

I agree. I've been a regular reader of the site for over six years (and a regular poster for 4.5 years) and I'm pretty sure this has gotten a lot worse in the last few years.

Headline-writing is very audience-specific. A headline that works fine in its original context (on a personal or company blog, for example) does not always work out of that context. In the early days, the "use original titles" guideline was much less rigidly enforced, and most users did a good job of tweaking titles to make them more informative and appropriate for the HN audience. When they failed, editors did a good job of fixing that.

Today it seems the rule is applied blindly and often detrimentally. And unlike, say, MetaFilter, where the moderators are visible and engaged with the community on questions of policy, the HN "editors" act invisibly and seem never to respond or engage with their readers. :(

For what it's worth, the old title was something like "Github Introduces Two-Factor Auth", which is a lot more descriptive and informative than the shorter title. Would like to know why it was changed.

I'm going to go out on a limb and say because the domain name in quotation marks, taken with the headline, clearly indicates that it's on Github and about Two-Factor Auth.

Github repo's also use the sam (github.com) format, so it's very reasonable that one would think this was going to be a git repo on github for two-factor auth, not that github as a website has two-factor auth as a login feature.

Nope, the whole rationale is "doesn't match original page title."

In the time it took you to get angry you could have just hovered over the link and seen it went to the github blog. Pretty obvious once you see that. It didn't need to say everything because if you look at the context, it was already there.

There are 19 more links at the front page, FYI. It actually takes a lot of time to hover all of them.

The point is not how much time it saves this user this instance, but rather that it is an on going site issue affecting tens of thousands of users.

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.

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.

> 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/

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.

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

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.

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.

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

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

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

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.

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

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.

Except the NSA party...

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

Excellent! Unless I'm missing it, it would be nice if there were a way to enforce a policy that members of an organizational team must have two-factor authentication enabled on their accounts.

It's great to see another big web service implementing two-factor authentication. Looks like 2FA is going to be a standard option in web apps in the near future.

I'm really glad that they didn't go the Twitter route and develop something completely new.

How is twitter's 2fa completely new? I use it and it behaves exactly like Google's does.

When they rolled it out, it was SMS-only. It still doesn't use TOTP - they've baked something into their mobile app that allows it to function as the second factor, rather than just supporting the same 2FA scheme that everyone else does.

Ah, I wasn't aware they didn't support TOTP; I only ever use sms based 2fa.

Since they don't use TOTP it's not possible to use their two-factor authentication with applications such as Google Authenticator or Authy. What's more, I don't think it even works with third-party Twitter clients (Correct me if I'm wrong), so you have to use Twitter's own apps.

It does indeed work with third-party apps using Google-style "app specific passwords". But I didn't know that it didn't support TOTP since I only use SMS authentication. I can see that as being a lame move, though.

I am an international student and I literally hate when they don't let me put in 2 different numbers. I get locked out when I travel. For example, twitter

There is a setting for a fallback number on https://github.com/settings/two_factor_authentication/config...

Use Google Voice or some other similar service that'll let you receive SMS via the web.

Be careful with that. A lot of automated SMS systems can't send to Google Voice.

Yup. I was not aware that some phone numbers were more equal than others when it comes to SMS service.

Good to know!

Wow thanks for that. I have Google voice account for forever and never thought about this.

Edit: This also connects every other account to my Google account, so I should only worry the Google account.

Bear in mind that if one login and password lets you get to both the password reset email and your SMS 2nd factor, you've turned two factor auth back into one factor auth. (So, then, turn two factor auth on your Google account...)

You are definitely right, but even though other accounts 2nd factor auth can be passed via password reset email, that would require a login to my gmail, but my Google account also has a two factor auth.

Edit: sorry for repeating you, I just show your footnote parentesis

Use an app, not the SMS service. Or get a spare phone to carry your "primary" SIM card in, receiving texts abroad are typically free.

What's the best hardware TOTP token to get?

This has been needed for a long time. Glad to see it finally materialize!

Shameless plug as this is another great use of my webapp http://gauth.apps.gbraad.nl/ (http://bit.ly/g2fauth) Just bookmark and use it offline. keys are stored locally.

The Chrome extension was forcibly removed from the Chrome Store as BigG was somehow not happy; you can however still install it from here: http://bit.ly/g2fachrome

Cool, I enabled it but had forgotten to download the recovery codes, next time I visited the site it bothered me to download them just in case, nice touch!

How long before we see it in Github Enterprise?


GitHub's 2FA just uses the industry standard TOTP like a ton of other places. You can use Google Authenticator, Authy, etc.

What fragmentation? I currently use 2FA on about 6 different sites. They all support Google Authenticator, so I only have one app on my phone.

TOTP is standardized. http://tools.ietf.org/html/rfc6238

I'm beginning to wonder whether "support for 2FA" is a way for companies to get your telephone number into their database. Does using an authenticator application also provide the same information to the company?

No: if you use (for example) Google Authenticator, your phone need never connect to network. The QR code you scan contains all that is needed to generate the code given the current time. Older versions of the Authenticator app didn't even have network access permissions; newer ones do because Google added the ability to automagically set up a Google account for 2FA.

Great move by the GitHub team! Glad to see they went with TOTP rather than SMS-only. As they mentioned on their site, Duo Security's mobile application supports TOTP and we'll have an Octocat logo in soon :)

Loving the app, get that logo in there fast!

I cannot use an Indian fallback SMS number. Wonder, what is behind that.

India has a strictly-enforced national do-not-call list (among other limitations). Twilio cannot send messages to numbers on this list (other SMS providers are probably in a similar situation). Github probably decided it's better to disallow Indian numbers completely than let you sign up with a number that may not work when you need it. http://www.twilio.com/help/faq/sms/are-there-limitations-on-...

We do send a test message before SMS 2fa is enabled. I just enabled support for +91. But given the other limitations in that article I'll need to keep an eye things.

All SMS providers are in the same boat. IIRC, the penalties for breaking the DNC list in India are brutal. (until recently I worked at a big mobile aggregator)

We just added support for India. Try again.

Okay, I can set an Indian fallback number, but did not get the SMS.

Hooray! Very nice implementation.

its very good to see github adding 2FA, but I wish they could also support their Indian users for using it via SMS.

edit : genuinely interested to know why they are not able to support SMS in some countries and mainly India.

See bdarnell's comment a few above yours. The problem is that India has a very strictly enforced 'do not call' list.

ing33k, give it another look. I just updated the supported countries list.

Does anyone have a good way of storing recovery codes? I currently keep them on paper, in my wallet, but with more and more sites using 2fa I'm having to carry more and more recovery codes around.

This may sound extra paranoid, but I've locked myself out of 2FA'd accounts before and recovery is not fun, so I go out of my way to keep the recovery codes secured but available to me in case of catastrophe.

First, I make an encrypted disk image with a very strong, unique passphrase (easy on OSX, not sure about windows). In this I put the QR setup codes and my recovery codes. I put a copy of this on every device I own, every computer I own, stash it in my home directory on my server, and put it on dropbox. I then share the dropbox copy to two friends, and instruct them to hold on to it in case I lose access to all my devices. Any time I enable 2FA on a new account, like I did today, I update the image and redistribute it.

I previously kept a copy on github as well as dropbox, but now that both are behind 2FA I wouldn't be able to recover from those sources if I lost all my devices. Maybe I should push a copy to pages.github.io under some secret path that only I knew.

Oh, and check out BitTorrent Sync, it makes it really easy to distribute among my computers and phone without worrying about dropbox somehow losing my files or preventing my access.

Screenshot all QR codes and store them in Dropbox, which also has 2-factor authentication. Store recovery code for Dropbox in Google Docs, which also has 2-factor authentication.

So for me to be totally screwed, I would have to lose my phone and have my logins expire on both Dropbox and Google.

Hasn't happened yet =)

Actually, I disagree with you here (because what hasn't happened to you has actually happened to me).

I was robbed at gunpoint, the perpetrator took both my phone and my laptop (the only computer authorized to login), which was the only computer that had a non-expired login.

I print out all the codes, stored them in a secure place in my house (with things like my passport). For the truly paranoid, get a safe, or a safety deposit box at a bank.

Not to mention the much more likely attack vectors with this approach over a safe/deposit box based approach (which you might be alluding to):

  - This has a big assumption that 2FA cannot be bypassed AND other service exploits
  are not possible. The recent Dropbox security paper showed this was possible:
  - Device stolen/lost/hacked with active logins to said services OR local copies of said 2FA
  recovery codes? Eek!
  - Our friends at the NSA love that you use Dropbox to store this versus a more
  secure service like SpiderOak.

I keep mine in a txt file on an IronKey. Something like a secure note in Lastpass would probably work too.

On-site robust safe and safety deposit combination.

Love it.

But Yubikey support as well please.

Having bought a Yubikey last week, I wish that Yubikey was better at TOTP (which I didn't realize that Github used, until posters here corrected me).

Right now there are Windows and Linux add on apps for Yubikey TOTP, but for OS X you have to pay $9 to a third party.

But then, I also wished that Yubikey supported PKCS#11, which looks like it may eventually be coming for the upscale Yubikey NEO.

Yubico is pretty cool in that they made something that is fairly programmable, but the better supported standards are not well supported by defualt.

As a Yubikey user, I wish more sites allowed the native Yubikey format, or even a VIP credential. TOTP doesn't make sense in a lot of use cases.

Nice. Wish it integrated with Authy though

Nope, nope nope nope nope. Authy's latest "innovation" where bluetooth on the host can grab a new code from your mobile device provides a direct link between your two factors (reducing them to one). I don't think their team understands much about the problem they're trying to solve and they seem to be watering down the security of the product to attract new users instead. DUO and plain TOTP are really the only ways to go.


For those who missed it before, from a previous discussion on Authy:

> You're correct - there are serious security concerns with Authy's product, which were pointed out on an earlier HN thread: https://news.ycombinator.com/item?id=4916983

>Personally, I'd be concerned with trusting my credentials with any company unless all members of the leadership team (yes, including "nontech" people) are incredibly familiar with basic security terminology and practices.

> (Note that the founder is unclear when PBKDF2 and AES are being used in the product, which is concerning, because they have very different use cases and should be hard to confuse).


[replying to my own post] Just a note, I talked with Authy on Twitter and they indicated they're making Bluetooth an opt-in feature in the future and that their management console has the ability to restrict all use of it by managed clients. I'm still not happy about it, but those are positive steps.

Great, so what should I use instead?

You can certainly use your Authy app for it, it's just Authenticator.

I would also suggest that any iOS users move away from Google Authenticator and towards Authy or another solution. Google Auth in iOS7 has been deleting labels, and even worse, deleting tokens, for many users. The app hasn't been updated since 2011 and there's been no word from Google on an upcoming update to fix the issue. With iOS7's launch/announcement next week, I suggest looking into a new TOTP app (like Authy) before upgrading.

Good advice. Indeed it looks like changes to the open source Google Authenticator app dried up in late 2011:


Doesn't necessarily mean the project is abandoned (as sometimes open source bits are sync'd periodically from more active internal trees), but.. sure doesn't seem actively maintained.

Can anyone here speak to Authy vs. Duo (as a regular user, not as someone providing 2fa for their site)?

Duo app doesn't store token data server side (authy used to last time I checked. -_-), and did not require a phone number to use totp.

I use duo.

I had all of those problems with Google Auth on iOS7. I just installed Authy and it seems to work great. I'd have paid $1-3 for it. I disabled the bluetooth feature though.

Looks like Google just updated their Authenticator app. Works fine for me on iOS7

> Looks like Google just updated their Authenticator app. Works fine for me on iOS7

Be aware that it will drop all of your existing tokens, so make sure your backup phone number is set & verified across all services and/or your have your backup codes prepped.

I added it to Authy with no issues. The only downside is that they don't have a github icon currently.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact