edit: correction, beating 2FA without phishing-- like in the post where he lost his account while asleep.
That's most definitely not true, as someone who works in this space. Plain old phishing is much more common, where the hacker tricks a user into entering their code into a malicious website.
To echo OP, this is why it's important to support non-phishable types of 2FA.
You can do this two ways, one of which will make more sense for your web site:
1. PCs/ laptops/ etc. can use little USB hardware devices, from outfits like Yubico, the word to Google or type into your preferred hardware source is "FIDO" although if you have spare cash and like cool toys FIDO2 is a more capable second generation of the technology.
In this situation the FIDO authenticator is your second factor. Your web browser takes responsibility for telling this authenticator which web site you're looking at, and it's just a dumb machine, so from its point of view obviously refunds-my-bank.example isn't mybank.example because those strings are different. The FIDO authenticator just does whatever the browser tells it.
This could be attacked by specialist malware, but it's tricky because the FIDO authenticator wants you to take physical action to trigger authentication, so the malware needs to not only tell the authenticator "Yeah, I'm totally er, Internet Explorer, and I need you to authenticate for mybank.example" but also persuade you to press the button or whatever to make it happen.
Or I guess bad guys can be like "please FedEx your FIDO dongle to us" if people really are that dumb, but then no need for phishing, just call people "Hey, I'm the IRS, send me $5000 in unmarked bills, in a FedEx box marked er cat food for some reason that totally makes sense, to a residential address in a different state, yeah".
2. High end smartphones, the sort with a fingerprint reader, can do the same exact trick using that fingerprint reader (I think some iPhones do facial recognition instead?) to do WebAuthn instead for their onboard browser.
In this case the smartphone is in charge of everything, it knows which web site this really is, it knows if that's really your fingerprint or not (the fingerprint never leaves your device) and it decides whether to send credentials.
For machines it's much easier to do a secure transaction, but machines don't fall for a lot of phishing scams.
This is actually built into most computers now -- Windows Hello, and Apple has something similar. Websites can check the attestation response to specifically block those, however. (Seems like Github allows it, and I've written code that allows it.)
> I think some iPhones do facial recognition instead?
Yup, they use whatever you use to unlock your phone. So if it's a FaceID phone, you can use FaceID to log in. You can also hold up your NFC Yubikey to the back of the phone and use that, even if you registered the key over USB on a PC! It's really, really good.
For the client side of things WebAuthn contains a standard option to block/allow "platform" authenticators, which I empirically know includes Windows Hello, and I'm not sure about Apple's or other equivalents. Of course you'd still want to verify the attestation on the server side.
You almost certainly do not want to do this for a public web site. If you insist on attestation right thinking people will hit "No" and block the site.
Think about it, what is attestation doing for you in this scenario? You're saying that you don't trust your users/ customers to pick the authentication methods that work for them, and instead you're going to insist on methods you prefer. Do you also choose each user's passwords? "No, sorry, that resembles an English word, we have selected the password 48'J3X$q)M3NBfr_2 for you instead" ?
In a corporate environment this could make sense. If you issue every employee a $100 FooCorp Security Key with their photo engraved on it, maybe you decide to require attestation that the keys used are FooCorp brand keys to prevent employees adding some off-brand Yubico product. I don't know whether that's a good idea, but it's no crazier than lots of corporate policies, however doing this for a public site makes no sense, please just skip attestation.
And there's no reason to do this! It's not like they're liable if I get my money stolen. If they prove 2FA was used and the security issue was on my device, not their app/server, it's my fault! As you said, if you're a custodian of something sensitive (an account, documents, money..), not the owner of it, it makes sense that the owner shouldd be able to dictate how you should protect it (like if you're accessing confidential company documents using 2FA). But in any other case, the service provider should never be allowed to force you to use a certain type of authentication device.
So old workarounds like using the lightning port are no longer necessary, though AFAIK are still supported. It's nice to have it there as well since to really be most effective every platform a user has needs to support hardware 2FA. If something still needs SMS or OTP or whatever that becomes the weakest link.
----
0: https://www.yubico.com/blog/yubico-ios-authentication-expand...
1: https://developer.apple.com/design/human-interface-guideline...
Firefox does NOT support Touch ID for webauthn
In 1) I don't think my YubiKey knows anything about the sites I use it for? It just creates keys, so a phishing site could presumably still steal the key created by YubiKey and pass it on to the real site.
2) My fingerprints definitely don't know anything about web sites. So WebAuthn being unphishable has nothing to do with fingerprints. It is only incidental that some devices decide to unlock the functionality with fingerprints.
2) Correct. In fact you don't even need a hardware token. You can do the whole thing in software. It could even theoretically be built right into your browser (but you would have the problem of logging in to the account on a different device or different browser). The fingerprint protects against physically stolen devices, and slightly against malware on your computer.
It's even a little bit cleverer than that. During enrollment (to say, Facebook.com) your Yubikey provides a random looking "identifier" to Facebook.com, and it promises that it can sign future logins if Facebook.com shows it the same identifier. The identifier is bound to the DNS name!
So a phishing site has a few choices, none of which help the bad guys even a tiny bit:
* It claims to be Facebook.com, but it isn't, so the web browser just doesn't even show the UI for Security Keys. There's a behind the scenes Javascript error basically, "What? You aren't Facebook.com fool".
* It admits its real DNS name, and makes up a random identifier. The browser gives the random identifier and the real DNS name to your Yubikey. But, it has never heard of this combination, so, it blanks the entire authentication figuring this must be for a different Security Key plugged in on another port or something.
* It gets that identifier code for your login from Facebook, and then admits its real name to your browser and provides the identifier taken from Facebook. This still doesn't match, and the Yubikey again assumes it must be for some other Security Key on your system.
Behind the scenes this is actually done with AEAD cryptography, maybe with AES keys baked inside your Yubikey. The "identifier" is actually something like a private key (likely elliptic curve parameters) that has been encrypted using an onboard secret AES key in an AEAD mode, with the DNS name (well, a hash derived from it) as a factor.
As a result, your Yubikey can't even decrypt the "identifier" correctly in order to log you in without the matching DNS name. This means goofs in the implementation fail safe - e.g. one brand of cheap Security Keys can fail to sign in once every 256 tries on average due to a logic bug. But they'd never sign in where they shouldn't because of mathematics, to do that they'd need to "accidentally" completely break the mathematical foundations of the cryptography!
Then again, it doesn't have to be the password manager that does this, but it'd be nice if it were integrated.
The browser will only give access to the Yubikey token for a specific domain name - so if the attacker phishes for examle.org, rather then example.org, then there is just no tokens (signing keys) available the Yubikey could use and give to the browser.
In the early days WebUSB in Chrome had bugs that allowed to bypass that same origin check but that has been fixed 3 years ago.
webauthn basically forces use of HTTP as the application level protocol, whereas a client side TLS certificate will work regardless of which application protocol is in use.
My FIDO authenticator has no idea who I am, no opinion who I am, so you can't use it to do identity correlation. It's only useful for the very specific problem we wanted to solve "Are you still you?" "Yes".
In contrast a client certificate for u801e is enduring proof you're u801e and signatures the client cert makes during login will be durable proof that u801e logged in. PornHub can show Facebook and GitHub that the same user is using their site. So that's a privacy hole you can drive a truck through.
There are numerous practical problems with trying to leverage TLS client certificates for this work, but that's a big privacy problem.
Client certificates can certainly be separated based on different domains. So, there would be no way to really determine my identity across multiple websites if I sent each one a different CSR and they each gave me different client certificates. The browser should only send the client side TLS certificate that's relevant to the server it's trying to connect to via TLS.
The main purpose of the client side TLS certificate is to verify the identity of the client on the server side, just as a server side TLS certificate signed by a trusted CA allows the client to verify the identity of the server. In the case of the client side TLS certificate, it doesn't have to be signed by an outside entity. There could be an internal CA the server uses to sign those CSRs and when the client connects, the server need only to verify that the client cert presented has a valid internal CA signature.
Why would you want passwordless authentication? Isn't the whole point of 2FA that you have to have something and you have to know something?
What's different compared to having a web site password? The web site knows the password, but they don't know your PIN. This means suddenly relatively weak human memorable passwords are good enough, because bad guys can't break in and steal 40 million of them in seconds or leverage them across multiple sites, the PIN is useless without the authenticator.
But other FIDO2 authenticators can do fingerprints, making it something you are (a person with that fingerprint) and something you have (the authenticator) so two factors again.
Usernameless (rather than passwordless) is the differentiator. You can literally have the sign-in flow be a "Sign In" button and the user does the thing (finger on reader, types in PIN, or maybe looks at camera) and they're authenticated. No step where you type in an email address or a username. This has a privacy cost because it means the authenticator knows in some sense who you are, but it is super convenient if that's what you're all about - while being much more secure than today's username + password dance.
Besides, there's nothing that dictates how secure the key should be. You could use your hardware cryptocurrency wallet for this, which is probably much more secure and convenient than the average Yubikey (you can duplicate it with the seed phrase).
Wouldn't the ability to duplicate it make it weaker?
> I wish he'd mention what kind of 2FA. The reason you _really_ should use U2F/WebAuthn is because it does origin binding which, unlike entering a TOTP, a code from your hardware token/authenticator app on your phone/SMS/etc is not phishable, i.e. you can't enter it by accident on accounts.google.com.totallylegit.ru and then have them enter it on real accounts.google.com. This is so because the U2F/WebAuthn security key signs a request, sent by your browser, which embeds the requesting page's domain, so a signature on attacker.com will not pass victim.com's verification checks, whereas a code from your authentication app is trivially copied.
It's also good to know that Yubikey's OTP tokens don't expire based on time, but based on a hidden counter that gets incremented with every issued token.
So if you've accidentally touched your Yubikey and leaked the token publicly, you just have to log out and then log back in using your Yubikey - that action will invalidate all tokens issued before this point.
The basic U2F + FIDO2/WebAuthn is the least expensive model, around US$25. These days it works seamlessly on Chrome, Firefox, and Safari.
There's also a WebAuthn extension in the works to at least make it easier to maintain a backup key by not having to pull it out of the safe every time you register MFA with a new service:
https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
Just don't click on giveaways and never enter your secret code
Phishing SMS and TOTP codes is way more common than SIM-swapping. Outrageously so. SIM-swapping does not scale. You need to call up a company each time you want to do it. Yes, it works. But you cannot sell a tool that just automates it. In comparison, there are many off-the-shelf phishing kits that fully automate SMS and TOTP 2FA theft.
Here is a description how it works:
https://github.com/wunderwuzzi23/KoiPhish
Unless you use Yubikeys (webauthn) etc these phishing attacks just continue to work. I do consultancy in this space at times and about 95+% of folks who enter their password will also enter their MFA token.
I only use Facebook trapped inside Facebook Container in one Firefox on one computer. But my understanding is that it's possible to sign in to Facebook from say a phone and a laptop at the same time, so the bad guys could get you to give them working credentials one day and persist those until you're asleep before using them. If you went to Facebook's security settings "Where you're logged in" and it lists two logins, one in "Paris" while you are in New York, you might realise there's a problem and force them out. But most people likely never look at that, why would they?
I can imaging some variant of outlook.microsoft.developer.really.yes.com catching me unawares one day.
I manage an authentication and identity provider and if someone gets locked out of 2FA and can’t prove their identity via a previously-uploaded gpg key, they get locked out for good. I never honor requests to reset the device sent by email, no matter how much they beg or offer to prove identity by sending copies of official IDs - I don’t care who they are now, I care about them being the same person that set up the account and 2FA, which can only be proven via a valid 2FA device or a GPG signature.
I'm not sure I trust that I'd be as good an attacker as a professional, and there's not a great way to replicate "hang up, call again" approaches likely to work with a big org.
Re-enabling the account after a certain period of time without activity would also be a good measure (on top of the id verification).
IMO, this is way too extreme for almost everybody. There needs to be some sort of happy medium so that a person who's lost everything they own (e.g., house fire) can get their account back somehow still. Two ideas I had:
1. When you set up your account, provide your legal name, date of birth, and a photo. If you need to reset 2FA, go somewhere in person with a government-issued photo ID (which we already have procedures to replace) that all of the details of match.
2. When you set up your account, provide 5 trusted contacts. If you need to reset 2FA, get 3 of them to agree.
Very few people are going to want to pay for this labor if the perception of risk of using a free account is as low as it is now.
Simply offering the option would bring the risk to the forefront of people's minds, and once you start exchanging money, lots of other thoughts and liabilities begin to enter.
If it is kept free, then the conversation ends there.
If you ever need to have this done, you'll realise how much house keys and door locks for many cases really only stop the opportunistic "pull the handle and see if it opens" attack. If your door has above average security they'll need to drill the lock, but the time I had to call one they could just push a tool through the letter box and break/move the bolt by applying leverage from the "indoor" side.
Same with 2FA. Just like a Locksmith it's a "human in the loop" situation where you'll need to give identification etc.
The rest of your post isn't relevant it's just about picking door locks.
I would bet that the post office employees are a bit less susceptible to the “hurry up and hit your metrics” pressure than someone at the Verizon call center.
I trust that it would be (potentially much) harder than normal, but it still seems to be possible.
I can think of options less extreme than keys gone = account gone that are still very secure.
e.g. To enable "Extra Advanced Protection" you have to visit Google HQ in your region, where your DNA is sampled. If you ever need to recover your account, you have to visit Google HQ again for another DNA sample, after which you're provided with account access, in person.
and who's gonna pay for that? Seems pricey and doesn't scale exactly well.
1) Get on with their day to maybe hit a support request quota 2) Make sure this person doesn't give them a bad customer satisfaction score
Eventually some required the last 4 of your social security number to port a number, which we all know at this point are pretty much public anyway.
T-Mobile now lets you set an arbitrary pin, which my parents promptly set to their DOB :facepalm:
I haven't looked more into it, but as far as I know, sim swap/port attacks were hilariously simple to execute which is why I only use SMS verification when it's the only option.
Isn't this vishing? https://youtu.be/BEHl2lAuWCk
How exactly does this get executed? I'm pretty technical, but I cant fathom exactly how this occurs;
You hijack a cell tower, then have some system to listen to un-encrypted SMS traffic??
Plz ELI5
I've worked with a bunch of streamers and YouTubers, and the threat model is such that people have shown up with professionally made printed fake IDs to attempt hijacking in an actual retail carrier store.
It shouldn't matter, because it's irrelevant to the point of the article, which is that Facebook (at least as reported) leaves a hacking victim with little or no recourse to get their account, and sometimes livelihood back.
An imperfect real-world analogy of your question is like asking about what precise brand of bear mace an assault victim was or was not carrying, and whether a better one would have helped. Perhaps it would have, but that's not the point. If having hardware tokens is so important, Facebook should be making them mandatory at its scale.
- You and I share a secret at my first login. Let's say our shared secret is "wibble".
- For any subsequent successful login with my username and password, for the second factor I send you the last six digits of the SHA1-hash of ("wibble" XOR current timestamp)
- You calculate the second factor yourself as well by doing the same operation (you have stored "wibble" for my username, and know the current timestamp), and verify those last six digits. If they are wrong, I am an attacker!
An accurate version: https://datatracker.ietf.org/doc/html/rfc6238
Like, what happens if I set my phone to a different time?
What if the server has lost connectivity to an NTP service and its clock is a few minutes off?
Some systems have some extra magic that allow the server to adjust for each device's clock skew; this was particularly important for hardware tokens that didn't have network connections. To imagine how that might work, suppose the server normally accepts responses that are valid at times t-2, t-1, t (the current time, per the server), t+1, and t+2. If a user consistently replies with the t-1 token, we know that her device is running slightly behind and we can instead authenticate against t-3, t-2, t-1, t, t+1.
The TOTP implementation for AWS logins is particularly prone to doing this for some reason, and you have to enter simultaneous TOTP codes to resync.
Imagine a hash function that generates a number from the number of minutes since epoch hashed additionally with some seed. You have it on the server, you have it on your, say, phone. When you enroll you share a seed for the generator. Since your time is synchronized, the server knows what value(s) to expect, and the phone knows which value to generate.
The real scheme is a bit more involved: https://en.m.wikipedia.org/wiki/Time-based_One-Time_Password...
(Note that most YubiKeys also support non-U2F modes, most commonly HOTP (HMAC(shared-secret, counter); counter +=1))
The exchange between browser and key includes the domain of the site. It only works on the same site where registered the key.
AFAIK some websites allow you to use the previous TOTP code for convenience for some more seconds. That makes the total time to impersonate you to be 30 (or whatever was configured while issuing the TOTP secret) plus the grace period websites allow.
Edit: formatting
"a code from your hardware token/authenticator app on your phone/SMS/etc is not phishable"
That certainly seems like it's wrong, and doesn't include an acronym other than SMS.
But apparently there's more depth to this space than I was aware of.
"U2F/WebAuthn is secure because it does origin binding which is not phishable, unlike entering a TOTP or a code from your hardware token or authenticator app or SMS"
Putting the original parenthetical in between the start and end of the main clause definitely makes it easy to misread. I just moved the parenthetical to the end of the sentence.
No, not always and many password manager solutions do integrate with your browser and know the domain for the password.
I wish he'd mention what kind of 2FA. The reason you _really_ should use U2F/WebAuthn is because it does origin binding which, unlike entering a TOTP, a code from your hardware token/authenticator app on your phone/SMS/etc is not phishable, i.e. you can't enter it by accident on accounts.google.com.totallylegit.ru and then have them enter it on real accounts.google.com. This is so because the U2F/WebAuthn security key signs a request, sent by your browser, which embeds the requesting page's domain, so a signature on attacker.com will not pass victim.com's verification checks, whereas a code from your authentication app is trivially copied.