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