Two-factor Authentication
github.com
github.com
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. :(
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.
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.
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.
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.
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/
(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.)
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.)
Yep. I opened mine one day and all my keys were gone. It's a real pain.
Edit: This also connects every other account to my Google account, so I should only worry the Google account.
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
edit : genuinely interested to know why they are not able to support SMS in some countries and mainly India.
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 =)
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.
- 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.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.
But Yubikey support as well please.
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.
https://code.google.com/p/google-authenticator/source/list
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 use duo.
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.
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).