Correct me if I am wrong, but passwordless login is a single-factor authentication and less secure than MFA. Depending on whenever hardware key is more or less secure than the password, the mass adoption of this could make things LESS secure.
If you go from MFA to fido2, maybe. If you go from single-factor password, to single-factor fido2 - it's likely security will improve. A lot.
> Depending on whenever hardware key is more or less secure than the password
It is:
A password can be sniffed, filmed, inferred from sound recording.
You don't know when someone knows your password; a key will be missing (or copied, but that's supposed to be Very Difficult (tm)).
A password is unlikely to encode as much entropy; certainly any password/phrase you actually type in. 128+ bits of entropy is surprisingly hard to encode in a manageable size (it's 16 completely random binary bytes).
Now, if the assumption is that the alternative is a ssh key locked on a device, additionally protected by a pin... Maybe The fido2 is slightly less secure.
But if you try and list the failure modes / do some threat modelling ; I think you'll see it ends up a close race.
It would certainly pair well with "something you know" - eg a pin/password with somehow proper rate-limiting.
Emphasis added. Device needs to be paired with Company's AD first.
I also imagine that there are options for making e.g. the device unlock only require yubikey, but login to SSO require 2nd factor.
In this context, it would be reasonable to have the Yubikey require a PIN entry from the computer. You could use the same PIN for all sites because it stays local; the relying party never handles it, only the Yubikey.
FIDO2 adds more options to the login process:
Single Factor: This only requires possession of the security Key to log in, allowing for a passwordless tap-and-go experience.
Second-Factor: In a two-factor authentication scenario, such as the current Google and Facebook FIDO U2F implementations, the Security Key by Yubico is used as a strong second factor along with a username and password.
Multi-Factor: This allows the use of the Security Key by Yubico with an additional factor such as a PIN (instead of a password), to meet the high-assurance requirements of operations like financial transactions, or submitting a prescription.
It's an option, not a requirement.
Also if it's at least approximately to password security this is very welcome options. Most services I use I just want access easily.
This is a big part of why you always want one of your factors to be something you know.
[1] https://en.wikipedia.org/wiki/Fifth_Amendment_to_the_United_...
Friends or family can't read your mind, but they can steal your physical key.
People putting pins on their phones or password on their laptop are not afraid of being pirated. This is a vague, abstract threat to them. Becoming part of a botnet is really not important to them, and they getting their credit card stolen from the web is really not credible enough for non tech saavy user.
What they are afraid of is other people looking at their stuff. Internet history. Pictures. Their clear text personal document.
Beside, a key is annoying. Where do you think they will store it when they travel ? In the same bag than the laptop. So you steal the bag, you steal the password.
Not only infeasible - physically impossible, in fact (barring quantum computers). Just 128 bits of entropy would take 1e16 (10 quadrillion) years to brute force at 1e15 attempts per second. :)
And of course you need a duplucate for the key.
Your example of people leaving the key with the laptop is a good example of one of the potential flaws, but just like if your credit card gets lost or stolen, you report it and it becomes unusable.
I agree that there is room for 2FA, but this is also surely preferable to the current system.
This is a false equivalence because knowing someone's credit card data only allows you to do one thing which happens to be pretty detectable: using their credit card for yourself.
Knowing someone's password allows you to know one or more of their secrets, including many applications that are virtually untraceable for the average user. So the deterrence factor is much lower in the second example making it much more likely that a nosy parent / sibling / SO will take a person's key.
There's no reason that using a password/key can't be just as detectable as using a credit card.
Also trying to trace logins application side is rather foolish IMHO, this should always be done at the authority that is granting the authorization.
That's not my point. The status quo is that people get alerted if something uses their credit card inadvertently and don't have similar alerts for uses of their password other than in a handful of situations like Gmail logins.
It's definitely not impossible for people to keep tabs on their logins, but this isn't how the Average Joe operates.
Plus, there's also the obvious solution for potentially stolen and misused keys .. just add a PIN.
For example if you have good physical security and limit passwordless login to physically secure machines via AD computer groups, this may protect you from remote attackers.
If however organizations allow the use of this over the internet from "any" endpoint then this completely replaces a password 1:1 and theft/loss of the Yubikey could be a major problem.
This could also be used only on a single layer of your security. For example passwordless VPN authentication but then a password/2F is required for actual user login.
That's completely outside the scope of what I was describing. You've taken my words out of context.
"We recently identified a bug that stored passwords unmasked in an internal log."
Because all they will have is a public key, not your secret password.
If your password is leaked, your username/email has probably been leaked as well.
If your hardware key is lost, assuming it wasn't stolen by someone who has specifically been trying to get your credentials, then there's nothing to tie it to you. You're still going to get a new key and change the locks, but you know it happened.