Passwordless authentication with FIDO2—beyond just the web

Posted Feb 22, 2023 11:50 UTC (Wed) by tialaramex (subscriber, #21167)
In reply to: Passwordless authentication with FIDO2—beyond just the web by mss
Parent article: Passwordless authentication with FIDO2—beyond just the web

Technically what the browser is doing is only deciding what names the site you're visiting is allowed to authenticate.

The WebAuthn API has a slot for you to say what DNS name you want authentication for. The browser gets to weed out unacceptable choices. They just get you an error in your Javascript and no user interaction. It is allowed for example for test-new.login.example.com to ask for credentials for login.example.com whereas it won't work if bad-guy.example asks for credentials for real-bank.example assuming example is a conventional TLD. The same mechanism is used to make this work as for cookies (the Public Suffix List).

But after FIDO is used to move an acceptable authentication request to your authenticator, the authenticator goes have the RpID and gets to decide what to actually do, my cheap Yubico Security Key 2 doesn't have any means to display a name, but e.g. if I need to log into a web site in a Chrome logged into Google on a Windows laptop, my Phone (which is also logged into Google) will light up - do I want to use my Phone's onboard credentials to sign into site.name.example on the laptop ? The name is right there for me to consider.

This required an impressive amount of lifting to do securely, the laptop has checked the phone is present using Bluetooth (so bad guys can't cause this to trigger unless they're nearby), but the actual security protocols are run over the Internet. And of course the phone is necessarily more complicated and thus has a larger attack surface area than my Yubico Security Key 2, but if your concern is primarily hard browser take over I guess this solves it.

Passwordless authentication with FIDO2—beyond just the web

Posted Feb 22, 2023 13:44 UTC (Wed) by mss (subscriber, #138799) [Link] (6 responses)

And of course the phone is necessarily more complicated and thus has a larger attack surface area than my Yubico Security Key 2

As I wrote above a network connected device (especially as complex as modern phones are) definitely has much larger attack surface than I expect from an authenticator token.

Passwordless authentication with FIDO2—beyond just the web

Posted Feb 23, 2023 1:18 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (5 responses)

A dedicated token with a display etc. would be unreasonably expensive and the threat just doesn't justify that. If you're so valuable that bad guys are going to spend an apparently unknown browser exploit *and* an apparently unknown phone exploit to target you, then your problem isn't really an IT security problem it's more some sort of personal security problem, FIDO and related technologies aren't really for you.

Passwordless authentication with FIDO2—beyond just the web

Posted Feb 23, 2023 10:39 UTC (Thu) by farnz (subscriber, #17727) [Link] (4 responses)

Well, FIDO2 is designed to allow you to solve this problem at some expense, if this is a plausible threat for you. This is why the authenticator gets the RpID, after all - to allow you to display it, and to confirm that the RpID on the authenticator is what the human in the loop expects.

But if you are such a high-value target, you can probably afford the expense of a custom authenticator that isn't a general purpose device, but does have a display and a USB interface that talks the authenticator side of FIDO2 CtAP. You don't need a full Linux distro for this - you could build such a thing on something like the STM32 platform.

Passwordless authentication with FIDO2—beyond just the web

Posted Feb 23, 2023 13:04 UTC (Thu) by mss (subscriber, #138799) [Link] (3 responses)

If you're so valuable that bad guys are going to spend an apparently unknown browser exploit *and* an apparently unknown phone exploit to target you

These attacks don't have to be targeted, but can be done against large number of people having the same phone model (for example).

Also, the browser and the phone don't have to be attacked at the same time - one can just wait for a vulnerability to be published and then try to infect as many devices as possible before people update.

At some point, after a few iterations, this will give the attacker a pool of (browser, phone) pairs which then can be exploited for nefarious purposes.

After all, the attacker needs to succeed just once (per device), while the defender has to successfully defend against every attack.

Well, FIDO2 is designed to allow you to solve this problem at some expense

"If you want good security you have to do it yourself" it's definitely not how security stuff should be done (sounds far too close for comfort to having a proprietary cryptosystem).

Even if you excuse this approach, it still doesn't solve the second problem that I mentioned in my original comment: For the same reason, using a FIDO2 token to approve money transfers wouldn't be secure in this threat scenario - you wouldn't be sure that you are actually reimbursing your friend $20 and not transferring out your whole account balance to a criminal.

Passwordless authentication with FIDO2—beyond just the web

Posted Feb 23, 2023 13:57 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

Taking away the emotive language, your claims boil down to:

My threat model says that the browser cannot be trusted to show the RpID, therefore the token must show the RpID.
My threat model says that all currently available COTS tokens that display the RpID are insufficiently secure.
I am not willing to use a token that isn't a COTS token.

This is fundamentally an insoluble cycle; if your threat model says that COTS security is not good enough, and you also require COTS security, then you cannot solve that cycle.

If, on the other hand, your threat model is a common threat model, then there's room in the market for someone to sell a secure enough COTS token with a display for your needs. Equally, you could produce your own FIDO2 token with an RpID display for now, and switch to COTS tokens (or pivot to selling your secure token) when the market is willing to pay for that.

And yes, FIDO2 explicitly isn't a transaction security mechanism - it's designed to function as an equivalent to passwords, SSH user keys, or TLS client certificates but with secure storage of the secret. A bank may well want a separate method to generate secure per-transaction keys, which would include details of the transaction and not just the password-equivalent.

Passwordless authentication with FIDO2—beyond just the web

Posted Feb 24, 2023 0:55 UTC (Fri) by mss (subscriber, #138799) [Link] (1 responses)

Taking away the emotive language, your claims boil down to

I don't think my points here contained any significant amount of emotion, just some example scenarios to make them more understandable.

If, on the other hand, your threat model is a common threat model, then there's room in the market for someone to sell a secure enough COTS token with a display for your needs

That's why I posted my original comment under this article - to make it clear that there are people interested in such functionality.

Passwordless authentication with FIDO2—beyond just the web

Posted Feb 24, 2023 10:23 UTC (Fri) by farnz (subscriber, #17727) [Link]

The comment I was replying to was an emotive attack on the idea that FIDO2 supports exactly what you want, and thus it's not a case of "build your own", but a case of "apply money to get an adequate implementation of the standard" - you suggested that "apply money to get an adequate implementation" is equivalent to "build your own with your own cryptosystem".

There is a huge gulf between "the standard absolutely supports what I want, it's just that if I stick to COTS parts, I have a choice between an implementation without a display but with adequate security, or an implementation with a display but inadequate security, or building a new implementation that supports both parts of the standard", and "you might as well build your own system, which is a known anti-pattern".