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.
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.
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.)
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 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
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-...
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.
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.
[+] [-] shmageggy|12 years ago|reply
[+] [-] mbrubeck|12 years ago|reply
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. :(
[+] [-] krebby|12 years ago|reply
[+] [-] jonesetc|12 years ago|reply
[+] [-] pilif|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] StavrosK|12 years ago|reply
[+] [-] rdl|12 years ago|reply
(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.)
[+] [-] Rizbo|12 years ago|reply
[+] [-] vulf|12 years ago|reply
[+] [-] andyhmltn|12 years ago|reply
Yep. I opened mine one day and all my keys were gone. It's a real pain.
[+] [-] Umofomia|12 years ago|reply
[+] [-] mwww|12 years ago|reply
[+] [-] signed0|12 years ago|reply
[+] [-] obilgic|12 years ago|reply
[+] [-] mastahyeti|12 years ago|reply
[+] [-] gaveeno|12 years ago|reply
[+] [-] mseebach|12 years ago|reply
[+] [-] jcurbo|12 years ago|reply
[+] [-] gbraad|12 years ago|reply
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
[+] [-] cheald|12 years ago|reply
[+] [-] jcastro|12 years ago|reply
[+] [-] jaryd|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] jeremymcanally|12 years ago|reply
[+] [-] kisielk|12 years ago|reply
[+] [-] mastahyeti|12 years ago|reply
[+] [-] aufreak3|12 years ago|reply
[+] [-] andrewaylett|12 years ago|reply
[+] [-] markstanislav|12 years ago|reply
[+] [-] movingahead|12 years ago|reply
[+] [-] bdarnell|12 years ago|reply
[+] [-] nathan_f77|12 years ago|reply
[+] [-] ing33k|12 years ago|reply
edit : genuinely interested to know why they are not able to support SMS in some countries and mainly India.
[+] [-] teach|12 years ago|reply
[+] [-] nothingsTrivial|12 years ago|reply
[+] [-] mastahyeti|12 years ago|reply
[deleted]
[+] [-] eric59|12 years ago|reply
[+] [-] vulf|12 years ago|reply
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.
[+] [-] maratd|12 years ago|reply
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 =)
[+] [-] packetslave|12 years ago|reply
[+] [-] hashtree|12 years ago|reply
[+] [-] buro9|12 years ago|reply
But Yubikey support as well please.
[+] [-] epistasis|12 years ago|reply
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.
[+] [-] bitsweet|12 years ago|reply
[+] [-] dguido|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] danielsju6|12 years ago|reply
[+] [-] Dobbs|12 years ago|reply