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.
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.
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
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.
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.
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.)
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.
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.
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
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
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!
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 :)
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)
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.
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:
https://www.usenix.org/system/files/conference/woot13/woot13-kholia.pdf
- 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.
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.
>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.
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.
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.
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
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.
