Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two-factor Authentication

github.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Two-factor Authentication

#81

Post by andyhmltn »

pilif wrote: post #40

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 sou…

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

Re: Two-factor Authentication

#82

Post by hashtree »

jonesetc wrote: post #65
shmageggy wrote: post #64

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…

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

Re: Two-factor Authentication

#83

Post by hashtree »

eric59 wrote: post #39

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.

On-site robust safe and safety deposit combination.

Re: Two-factor Authentication

#84

Post by hashtree »

YuriNiyazov wrote: post #43
maratd wrote: post #41

Earlier quoted context omitted.

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 sa…

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.

Re: Two-factor Authentication

#85

Post by [deleted] »

YuriNiyazov wrote: post #43
maratd wrote: post #41

Earlier quoted context omitted.

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 sa…

[deleted]

Re: Two-factor Authentication

#86

Post by sneak »

krebby wrote: post #67
shmageggy wrote: post #64

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…

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.

Re: Two-factor Authentication

#87

Post by mbesto »

sneak wrote: post #86
krebby wrote: post #67

Earlier quoted context omitted.

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.

Re: Two-factor Authentication

#88

Post by andrewaylett »

aufreak3 wrote: post #63

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.

Re: Two-factor Authentication

#89

Post by dguido »

dguido wrote: post #14
bitsweet wrote: post #2

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 t…

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

Re: Two-factor Authentication

#90

Post by rdl »

pilif wrote: post #80
rdl wrote: post #69

Earlier quoted context omitted.

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

Post reply on HN