This is great forward progress, I much prefer U2F where available. I hadn't even realized that FB supported 2fa, so I just tried to set it up on my iPhone, and either automatically or manually cannot get a test code to work. This tends to reduce my confidence in any other aspect of their implementation
I have to admit to being quite startled. But I just get "Security code was invalid. Please try again". I've tried again several times. I'll see if setting it up on the website works.
counter-anecdote: I've had zero issues with FB 2FA and I'm pretty sure many, if not all (I would hope it's an internal policy, but idk...) FB employees have it enabled, so it'd be pretty difficult for them to not notice serious issues with the use of their implementation (as your post suggests exist).
"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.
Good question. I am not sSure you can do it without using SMS to bootstrap the process, but if you have TOTP set up and then turn on U2F (with TOTP as the backup) then I think you can disable SMS messages.
So digging around a bit on the page the 'Learn More' in the login approvals (https://www.facebook.com/help/148233965247823) claims that you can turn off SMS codes, but I no longer have the advantage of being able to walk over a few desks to get a real verification :) I may try to set up U2F later today and see if this actually works...
You would also need to turn off login notifications (section just above login approvals in the security settings page.)
Having something like yubikey is better than just SMS given the phishing attack scenario will have to convince you to type in the SMS code, which should set off alarm bells if you have a functioning yubikey installed on the device you are logging in from.
No, that's not the problem with SMS. The problem with SMS is that SMS is itself insecure; in fact, there are large parts of the world where it's overtly and directly state-controlled. You won't have to enter your SMS code; the attacker will do it for you.
I had SMS as my backup and in testing this morning, FB sends the SMS by default, even before you either tap the key or say you want to use another method (like SMS).
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.
I'm not sure I see the security advantage to opt-in SMS over opt-out SMS (both are bad). If the button exists to override the hardware token with a text message, the attacker will simply push the button after hijacking your phone number.
True that. More of an annoyance then with my phone lighting up with an SMS notification that I didn't need. Reminded me to disable SMS 2FA and stick with the authenticator app.
I'm happy with Authy and TOTP, for the moment. Getting a YubiKey has been on my to-do list for awhile, but I'm not sure that everything I currently have 2FA for will accept it. In which case, I don't like the idea of half-migrating to Yubikey while still having to keep Authenticator around.
Pretty much everyone I've talked to that uses a YK has the same configuration I do, by priority:
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.
You can use your Yubikey + Yubico Authenticater to replace Authy. It does not add that much security, but you add device switch ability without Cloud Sync.
Yeah the NFC on my Yubico has burnt out. Or something. Regardless, Yubico Authenticator just flat-out didn't work for me. I got it running, loaded some codes, and then the codes didn't work again. It was like it lost synchronization with the server clock or something. I had the same issues on Android and MacOS. Maybe I could have sorted it, but I lost interest before finding a definitive fix.
Happy to see Facebook finally supporting U2F but haven't assessed how robust their implementation is.
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.
This is really awful, for it to work well you would need to buy multiple keys and each time use them all to register (which precludes the option of storing the backup key somewhere safe).
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.
Part of the point of hardware tokens is that you can't back up and restore their keys. If backup and restore is important to your userbase, you should stick with soft tokens.
The trezor only lets you backup the key during the initialization stage. After that the key can never be recovered. Also you can set a password so it's encrypted as well, so even if someone finds your paper backup it's not particularly useful.
If there can at some point in time be two or more tokens with the same secrets in them, you're essentially parked in the same security place as soft tokens. Just use the soft tokens.
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.
Could you elaborate on this, please? It's contrary to my intuition, and I respect your opinions on the subject. Having an auditable hardware token shouldn't preclude backup and restore? It still reduces the surface area for vulnerabilities to an object with no radio.
I'm worried at this point that I'd be repeating a comment I've made on this branch of the thread, so can I ask if you have any questions about those responses?
I disagree that it's undesirable for back-up and restore to be impossible in all cases.
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.
I wouldn't personally recommend backing up and restoring 2FA secrets; there's a reason that the printable backup codes you get are one-time-use. But if you're going to do that, don't bother with hardware tokens. I mean, use them if they make you feel cool (I'm not being derisive; there's value in feeling better), but understand that you're effectively turning your hardware token into a software token by doing that.
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.
I'm still working on it, but it's a one-man company at the moment and I have more than one product so I'm spread pretty thin. But yes, I need to update the manual at the very least to mention that it now supports U2F. Thanks for pointing that out.
I am slightly disappointed that this doesn't work in Firefox, despite the fact that I have an add-on[1] installed to add U2F support. Github for instance is able to detect U2F support and let me use it.
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)
FLAC audio support is simpler, it's just adding a self-contained FLAC decoding library, and wiring it to the already-existing audio code.
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.
The USB part is the simplest part. U2F uses USB HID for messaging. That's probably less complicated than using the D-Bus interface. And anyhow there's probably already an open source library for U2F USB HID clients. Mozilla will probably use whatever Chrome is using.
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.
I just implemented U2F, and it's a bit of a pain to detect that the plugin is there. You have to load the real u2f js, then check if functions on the u2f object that are normally there aren't anymore, since the firefox plugin strips all of them off but 2. Doable, but a pain.
Facebook engineers responded to this in the U2F issue on the Firefox issue tracker. It turns out that for this particular technology determining whether or not your browser supports U2F is not yet feasible, so they resort to user agent sniffing. You can use Firefox with the third party plugin if you spoof the user agent to Chrome.
Last time I looked at Facebook 2FA, it didn't allow you to enable it unless you had a browser with old enough cookies from Facebook, which is not possible if you configure your browser to clear all cookies on exit (and close the whole browser at least once a day). Is that still the case?
I've used Facebook 2FA for quite a long time now and all of my browsers are configured to clear cookies on exit (and to disallow 3rd party cookies). Didn't have any issues with activating 2FA.
I've been a big fan of yubikeys for years, but I'd never use mine for something like Facebook.
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.
If my network knows that I use PGP to login, they may well accept an (illegitimate) announcement that I'm changing my keys to {attacker-generated.asc}.
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.
It doesn't increase severity in and of itself, it just changes the nature of the system. And people will adapt their decision making processes to the new properties of that system.
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.
I don't understand, and I'm really trying. What's the additional failure mode --- one I don't already have --- that might get added because of the moral hazard of me having a U2F token?
I'm not saying they come as a package. My original post was only about Facebook's future product decisions after a hypothetical point where they get a large enough portion of their userbase to use 2FA.
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.
I think he was saying something along the lines of:
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.
>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.
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.
Looks like a logistical nightmare to me. You think forgetting a password is a pain in the ass, just wait until you loose your security key. It won't be one service you have to reset through an alternate verification route, but every single one you ever used! I also foresee potential issues with data corruption on keys, and multiple-keys getting out of sync (e.g. work vs home). And I have no doubt that clever hackers will find ways to get the codes off those keys (they will be plugged into a computer all the time and at the very least even the most cautious are susceptible to phishing). 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 -- but I suppose that's also why the big companies want to get rid of it, SMS costs more money.
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.
Is it really that big a deal? I just have it on my key ring, which I'm not really in danger of losing. And if it is a concern, get something like Tile or TrackR. Seems less likely than forgetting the 15-character fully random passwords we're supposed to memorize.
I recently lost my security key. Now I have to pull out my phone and type in 6 digits from Google Authenticator instead. It's been such a nightmare, let me tell you..
One issue with buying two keys is they internally have different keys, so you need to connect both to each new account which is a pain in the ass and stops you just keeping one somewhere very safe (i.e. safety deposit box, or a safe at a friends house)
That's like saying you shouldn't lock your house because you might lose the key.
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.
AFAIK, there's no "codes in stasis" in U2F. http://google.com/ sends you a challenge, your U2F device receives the challenge and makes a response signed with the private keypair that exists. Each CR pair is nonced and only valid for the originating site.
Don't plug anything in your computer that you don't trust. And "trust" doesn't just mean "trust them to be non-malicious", but also "trust them to competently secure themselves against malware"
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.
We started using these for internal services and Google accounts where I work. It's unfortunately a big pain in the butt- you can't use Safari, you can't use the Mac/iPhone calendar app to see your meetings. It's web apps in Chrome or nothing, more or less.
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.
Huh? I use the Google applications --- and, particularly, their calendar --- all the time without using Chrome, and U2F is my first-priority 2FA mechanism. You can mint static random application keys for your native applications, and use TOTP as a backup for when you want to use a different browser (really, though, you should use Chrome as much as you can; it's significantly more secure).
For some reason application passwords don't seem to work according to everyone who tried. I don't really know what TOTP is or how all of this is configured, that's the domain of our security team. I don't really know what you mean about Google apps, I just want to use the calendar app on my Mac and iPhone to see my meetings but I can't. I asked them about it and they confirmed to me that I should use the Google Calendar web app in Chrome.
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.
Well you said yourself that you are not an expert. I encourage you to actually play around with the settings a litte. I have used it multible times in different context and it has worked like a charm every time.
So maybe if you spend some time on it, you can make it work.
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.
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?
That video doesn't seem particularly relevant to the question; it talks about fake likes, but makes the point that those fake users don't engage with the content at all.
As a huge fan of U2F I really love this. I don't use Facebook, but we are starting to cover more and more of the internet. Facebook, Google, Dropbox are huge.
I wish Facebook brings something similar to the Instagram.
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.
Same exact thing happened to me on Instagram. Which is crazy to me, its really the first time I was hacked, as I usually am very careful with passwords and security. I used 2FA and password managers and so forth.
104 comments
[ 2.9 ms ] story [ 188 ms ] thread"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.
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.
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.
https://sc4.us/hsm/index.html
(Full disclosure: this is my company.)
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...
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 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.
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.
So which is it?
... but physical access is game over no matter how much epoxy you use.
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.
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.
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?
I would like to see UAF also get some more love.
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...
2
3
4
5
6
7
8
9
comments...