Security Key for safer logins with a touch
facebook.com
facebook.com
That said, I understand the lack of support since I am an extremely small niche, and this did prompt me to finally add 2FA to facebook (U2F and code generation from my Yubikey Neo)
[1] https://addons.mozilla.org/en-US/firefox/addon/u2f-support-a...
The tree of bugs to follow is rooted at https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
For U2F, they have to write code to interact with the operating system USB API (for each operating system), plus the main U2F code, plus a Javascript API, all while taking care to not cause any new privacy leaks or worse.
If you want to follow, the main bugzilla item seems to be this one: https://bugzilla.mozilla.org/showdependencytree.cgi?id=10657...
Reported: 2014-09-10 16:07 PDT by Axel Nennker
Modified: 2017-01-26 08:24 PST (History)
CC List: 419 users (show)The real complexity is in exposing the interfaces through Javascript and orchestrating all the GUI components. In fact, U2F doesn't even require a hardware token. It was designed so browsers could implement everything in software to hasten adoption.
"Doing feature-detection of a U2F API instead of User Agent sniffing would have required additional engineering effort due to how our system already works" (https://bugzilla.mozilla.org/show_bug.cgi?id=1065729#c264)
I recently got hacked and lost my account and my first name username for good[0]. They don't even allow 2 factor auth on accounts with low followers there.
[0] https://medium.com/@batuhan/i-got-hacked-and-i-dont-think-in...
https://github.com/amluto/u2f-hidraw-policy
I need to get around to integrating this with upstream udev so it can stop being needed as a standalone project.
No, really, it is. Theirs is a little list of known U2F devices from known U2F device vendors. Mine actually detects the the device is a U2F device regardless of its make and model. As far as I know, Yubico wrote that spec, so I'm a bit surprised they didn't implement it in the udev rule.
Another U2F hardware key is the Trezor bitcoin hardware wallet ( https://blog.trezor.io/secure-two-factor-authentication-with... ) which has the added benefit that you can backup all your U2F private keys. I'm not aware of how you could do this with a Yubico U2F key -- if someone knows, please enlighten me.
Straight from the yubico website: "It is recommended that users register at least two U2F devices with every service provider should a U2F device be misplaced"
That's just a plain usability nightmare, and not to mention expensive.
The trezor one works a lot more sanely for u2f, you get a recovery key when you first set it up (it uses the screen to output it, so even if your computer has malware it can't be compromised) and can leave it in a safe at your friends place.
I'm not saying soft tokens are bad. They're not; they're great. When we get a workable U2F software token, that might be the best option for most people.
What I'm saying is don't spend money on a hardware solution that isn't buying you any meaningful additional security.
Instead, I would argue that plain-text export of private and secret keys is undesirable, as it removes any protections the HSM was supposed to provide (2 man rule for access, audit of use, etc). Back-up schemes that export these keys (in encrypted form) to another HSM that enforces the same rules as the original HSM can be useful, IMO.
My point is not that backup and restore is intrinsically evil; it's a legit security/usability tradeoff. I think most people should use software tokens.
(Full disclosure: this is my company.)
1. Security key
2. TOTP via phone authenticator app
3. Offsite saved backup keys
(4.) Disable SMS
This implies two things: first, that for pretty much every site you rely on, you're going to be both TOTP and U2F anyways, and second, that sites that don't support U2F yet will just start at step 2.
U2F is more convenient than TOTP and, because you're virtually never going to actually use it on a site you U2F into, U2F is still mitigating the phishing risk. You're carrying your phone with you anyways. It's pretty much win-win.
The one type of key supposedly uses Bluetooth, but that functionality isn't built yet or something, so you get to carry around a little 4-inch microUSB cord with you everywhere you go, and connect that every single time you hit a 2FA prompt. At least the Yubikeys have a USB connector built into them.
Using a web app on my Mac isn't the end of the world, but I can't see my meetings on my phone in any type of way, and I'm already missing them sometimes because the little notification on the phone is what reminds me that I have a meeting to go to.
So maybe if you spend some time on it, you can make it work.
https://support.google.com/accounts/answer/185833?hl=en
One key caveat with these -- they grant access to your whole account, just like your real password. They don't give access to a specific scope (e.g. calendar) even through that might be all the application you're syncing needs.
I work in computer security, so I know this sounds crazy. But my brain has been rewired to work in failure modes by the not-security domain I happen to do security stuff in.
The obvious argument for TFA is to reduce the chances that my Facebook account is subject to the bad consequences of that come from a compromised Facebook account.
I'd much rather they reduce or eliminate the severity of the failure mode in the first place. TFA is only a mitigation that reduces the likelihood of account compromise. It shouldn't be possible for someone who swipes my yubikey to do any more than cause a minor social annoyance.
Unfortunately the presence of the mitigation (TFA) will - if adopted to significant numbers - combine with Facebook's other incentives to produce more severe failure effects for account compromise.
Remember back when facebook was still in it's just-college phase? And dicking around on your friend's facebook account if they left their computer unlocked was normal? And when you saw someone acting unusual, you sorta assumed someone was messing with their account? Yeah, I don't want a compromise of my facebook account to ever be more severe than it was back then.
Of course, really such a login key should only be able to authenticate, and my network should only accept a proper revocation certificate that would need to have been generated by a different key with the 'Certify' action enabled.
How likely or damaging that is obviously depends a lot on who you are, and probably wouldn't be for many people at all. But I assume that's the sort of thing your parent commenter is alluding to.
Facebook would feel more comfortable expanding their scope of features in a way that increases severity. -- For example, my primary objection to using my facebook account to log into unrelated websites isn't about privacy, it's that I think I can manage unique credentials for each one better than adding facebook as a shared point of failure and risking a cascade if my facebook account gets compromised.
Contacts would assume a higher degree of authenticity to actions done with my account.
It only sets the stage for the change, it doesn't implement it. I know the tech bubble likes to pretend speculation around obvious system effects is 100% unfounded if it might lead to even-the-slightest-bit-unflattering conclusions. But I don't play that game.
You don't have to mitigate failures modes that don't matter.
When you have existing mitigation in place, you can add more failure modes/effects "for free."
Edit: I don't want my facebook account to become the _kind_ of thing I'd want to protect with 2FA = I won't use 2FA for facebook.
It seems as though the same thing could be said for having any password at all on a Facebook account?
If you increase the strength of the authentication on an account, then you increase the expectation (in others) that anyone authenticated to the account was authenticated legitimately.
So, for example, if you have weak authentication and illegitimate access is common, then others are accustomed to distrusting the service and will react accordingly (for instance, by discounting weird behavior as the result of a hack).
However, if you have strong authentication (via 2FA) and illegitimate access is uncommon, then people are accustomed to trusting the service, so they will be less likely to correctly discount and distrust weird things posted by illegitimate actors.
Basically, I think he was saying that for something low-value like Facebook, 2FA is a bad bargain because it trades a stronger social mitigation for a weaker technical one.
But that assumes that your login methods are provided to your social network. No one necessarily knows I have 2FA/U2F, so if I am compromised, I still have the same general assumption in my social network of "oops plttn left his Facebook on his laptop unlocked".
1. You ensure your FB account isn't valuable, in order to decrease the bad effects of it being hijacked.
2. You argue that hardening against hijacking means eventually the stakes of hijacks get higher, and therefore we shouldn't be hardening. Is that correct understanding? If so, that's short-sighted at best.
Many accounts are extremely valuable. It can be in terms of actual money, career, influence, politics, etc. For some people it is the primary vehicle for their livelihood. Same goes for many other online services, that open possibilities for people to earn a living, partake in politics/governance, and maintain social relations that they otherwise could not.
Does anybody know why the comments under this post are like that, at least for me? Is there a particular reason why people from Myanmar (some with latin name?) would comment this much more than any other?
The more I think about it, it seems to me that the Internet itself really needs to be a two-channel system. If communication has two separate physical channels then it becomes much easier to ensure security.
w.r.t:
> I also foresee potential issues with data corruption on keys, and multiple-keys getting out of sync (e.g. work vs home).
and
> Also, it just doesn't seem as secure as an SMS code b/c the SMS code doesn't exist but for a short window of time and is transmitted by a completely separate communications channel
Are you talking about U2F? There are no synchronization issues there. And it is more secure than OOB codes because they can be phished. For U2F your browser is in the loop, and the origin to which you are authenticating is folded into the signature. Thus it is detectable by the RP if the signature was generated on a phisher's non-legitimate website.
I would like to see UAF also get some more love.
"Security keys for Facebook logins currently only work with certain web browsers and mobile devices, so we'll ask you to also register an additional login approval method, such as your mobile phone or Code Generator"
So as usual, the U2F standard being adopted by companies these days is only as strong as SMS 2FA, because of this requirement.
Can someone tell me what's the point then? Is it that they hope that in the end U2F will get popular enough that they'll remove that requirement? I would hope that's it. Otherwise, I don't see the point.
I wish they at least allowed you to opt-out of the SMS back-up before you even had to give them your number. Of course, we're talking about Facebook here, so they won't waste any opportunity to make it seem like you have no choice but to give them your phone number.
(It's very possible that I'm dumb!)
You would also need to turn off login notifications (section just above login approvals in the security settings page.)
A requirement to have one backup, which doesn't have to be SMS. It appears to allow a manually pregenerated list of codes, for example. See the ui: https://scontent-dft4-1.xx.fbcdn.net/v/t31.0-8/p720x720/1617...
That's a big flaw to me. It should only send the SMS if I specifically say, "Use my backup SMS method". I switched to use an authenticator app instead as a result.
So which is it?
... but physical access is game over no matter how much epoxy you use.