LWN: Comments on "Passwordless authentication with FIDO2—beyond just the web"

Passwordless authentication with FIDO2—beyond just the web

Cyberax — Sat, 04 Mar 2023 00:02:18 +0000

Yeah, the proposed "passkey" infrastructure as of right now is barely more secure than a password manager with a good master password. One easy way to improve security would be moving all the passwords into the secure enclave, with hardware-enforced rate limits and biometric authentication.

The synchronization can then be done using the regular public/private key exchange between enclaves.

Unfortunately, as of right now, Apple's secure enclave is not up to the task. Its public API only allows hardware-based P256-based encryption/decryption. It's also impossible to export the private key or import your own. So it can be used to protect individual passwords, but they'll have to exist as plaintext in system RAM at some point. It's not possible to move all the crypto to the enclave :(

Passwordless authentication with FIDO2—beyond just the web

tanriol — Thu, 02 Mar 2023 20:11:59 +0000

If I recall correctly, another neat trick of FIDO2 is that in many cases (other than the "resident credentials" feature) the private key handle is actually the private key itself encrypted with an authenticator-private root key. That means both unlimited authenticator capacity because it doesn't need to store any per-credential data and being unable to list credentials based on this authenticator.

Another side that may be a drawback is that authenticator-based credentials often are non-portable (cannot be exported from the authenticator device like a Yubikey), so services need to support multiple credentials per user and users actually have to have (and store in some reliable way) fallback credentials. The latter part of this problem seems to be in process of being solved by "passkeys", which (in this part) boil down to "cloud FIDO2 credentials provided by your ecosystem vendor", i.e. using your Microsoft/Apple/Google/... account both as a way of syncing them between devices and as a backup, plus a standard way to "authorize sign in on the new device from the old device" for the case when the two devices belong to different ecosystems or the user doesn't use credential sync for any other reason. That's going to be a variant that'll be less secure than hardware-based FIDO2 credentials, but more usable for a lot of users.

Passwordless authentication with FIDO2—beyond just the web

nix — Tue, 28 Feb 2023 22:34:07 +0000

> With all this functionality of FIDO2 security keys, one has to wonder why traditional smart cards or hardware keys implementing OpenPGP aren't enough. These have been used for a long time to store private keys offline for encryption, authentication, signing, and verification. Van Dijk considers that the biggest advantage of FIDO2 security keys is that they are cheaper and more user-friendly.

Honestly that's an understatement. GPG-related key handling on Linux remains a flaming nightmare, mostly because despite years of work and bugfixing the libccid / opensc / pcscd / gpg-agent house of cards still cannot handle obscure rarely encountered cases like "I've gone to lunch and unplugged my key and taken it with me as I'm supposed to, when I get back and plug it in again I expect things to work and do not want to have to exit all my ssh sessions, kill -9 a horribly hung gpg-agent and pcscd then restart everything again, possibly being restricted to one tty for my sshes unless I copy/paste env var settings around". Debugging this has faded from my memory, but I vaguely recall that it requires compiling piles of things in the ccid/pcscd ecosystem with special flags and (IIRC) running them in unusual ways and then if you're lucky you get protocol dumps in strange places which you can dig through. I have not yet been sufficiently motivated to learn the protocol in question, so my debugging generally stopped there.

Meanwhile, with libfido2 this all just works with every key I've tried, proxying over ssh-agent flawlessly, no admin effort required: disconnection is fine, other things like GPG or PIV handling temporarily locking the key is fine as long as they let it go again, everything works. (I suspect pam_ssh_agent_auth might let me use pam_u2f on remote machines too, proxying back over the ssh agent connection, but I haven't tried that yet.)

Passwordless authentication with FIDO2—beyond just the web

Cyberax — Tue, 28 Feb 2023 21:58:10 +0000

I believe that the "airplane mode" still disables it. Also, realistically attacking through the baseband stack requires CIA-level expertise. It's highly unlikely that they are going to burn their secret baseband exploits just to get to me.

So I think that in practice disabling the Internet access should be enough for all, but the most paranoid applications.

Passwordless authentication with FIDO2—beyond just the web

nix — Tue, 28 Feb 2023 21:36:41 +0000

> An area that I don't think it necessarily improves on is device security, particularly for portable devices. Specifically if my laptop bag is left on the train, it is likely that my FIDO2 token is also in that same bag.

I keep it on my keyring. Anyone who can steal that with enough info to actually use it also knows where I live, and given that my front door key is also on the same ring I then have bigger problems (including physical access to most of the machines protected by the FIDO2 token, but honestly they'd be *in my house* and I'd be more worried about that)

Passwordless authentication with FIDO2—beyond just the web

nix — Tue, 28 Feb 2023 21:33:20 +0000

> Mobile radio is useless without a SIM card

Even without a SIM card, the thing connects enough for voice emergency channels (by law in many countries), which means most of the crazy mobile protocol stack and closed-source crawling-horror baseband processor is up, backdoors and all.

Passwordless authentication with FIDO2—beyond just the web

spacefrogg — Tue, 28 Feb 2023 16:09:58 +0000

In Germany, it is also common to validate single bank transactions via QR-Codes as a newer implementation of CAP. The added benefit (from my point of view) is that the authentication device is airgapped. While it can read the QR code, you must input the resulting TAN manually into the browser. So, you can be reasonably sure that you only authenticate the transaction your are interested in (and no hidden transaction that runs on a compromised device). The added bonus of QR codes is that you can validate their content independently with your smartphone etc. So, you don't even have to trust the down link.

Passwordless authentication with FIDO2—beyond just the web

farnz — Sat, 25 Feb 2023 15:00:38 +0000

Underlying this is the threat model, pairing up a risk with a mitigation. For BankID and similar systems, the risk that's being mitigated is the bank's risk: "if I cannot prove that the user authorised this transaction specifically, I am on the hook for reversing the transaction at my expense, and may be completely out the money that was involved if I cannot reclaim it from the recipient".

In this threat model, fraudulent transactions authorised by the user are absolutely fine - if I can confirm that you really did authorise sending 1,800,000 kr to "Steal Money-Bank Fraudsters", then I'm off the hook, even if you actually meant to send the money to "Stockholm Mercedes-Benz Franchise".

Similarly, FIDO2's threat model is that user-controlled shared secrets (a.k.a. passwords) are too easy to steal from one site and use for access elsewhere, and too hard to change after every use - e.g. plenty of people have the same password for GMail, Amazon and their bank. FIDO2 wants to change this so that authentication is done via a public key authentication protocol, so that even having a keylogger on your GNOME desktop is not enough for me to authenticate as you at a later date.

Passwordless authentication with FIDO2—beyond just the web

hpro — Fri, 24 Feb 2023 20:37:01 +0000

In any case, the true threat model for the vast majority of users has nothing to do with MITM-attacks. The Swedish BankID system, and similar implementations are a case in point. They provide the user with an app on their phone which will prompt them for confirmation with PIN or biometrics with a nice display clearly showing what they are authorising.

And the vast majority of frauds occur not because users authorise transactions on malicious sites, but because someone calls them pretenting to be the bank and convinces them to authorise an actual login / transaction for their actual bank on their phone to "confirm their identity" or "sort out a minor issue". No mitm needed.

The app now supports scanning a QR to initiate a login, which makes this harder, but still not all use it, so the vast majority of fraud is done through coercion and social engineering, not hacking afaiu.

Passwordless authentication with FIDO2—beyond just the web

farnz — Fri, 24 Feb 2023 10:23:48 +0000

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

Passwordless authentication with FIDO2—beyond just the web

mss — Fri, 24 Feb 2023 00:55:37 +0000

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

Cyberax — Thu, 23 Feb 2023 21:30:46 +0000

Realistically, how is the phone going to connect to the Internet? Mobile radio is useless without a SIM card, and you can just avoid connecting it to WiFi.

Passwordless authentication with FIDO2—beyond just the web

NYKevin — Thu, 23 Feb 2023 17:54:59 +0000

You're thinking about this in absolutes. The purpose of SAK is to impede malware from moving laterally through (mostly) corporate/NGO/etc. systems (in principle, anything that is large enough to qualify as "an intranet"), not to provide a security boundary. It's a defense in depth measure.

Passwordless authentication with FIDO2—beyond just the web

tialaramex — Thu, 23 Feb 2023 15:11:37 +0000

This only makes sense if your absolute minimum acceptable security is the attested device. If your model says nope, anything less than that is a disaster then I guess attestation is a viable way forward for you, although my guess is also that a subsequent audit would turn up numerous holes you forgot about while focusing on this very slim problem.

On web, and in my experience at most larger corporate systems, the minimum is far worse than this, and so necessarily unattested devices are actually a big improvement on the status quo.

Going from "Got a valid password from the phishing email, we're in" to "If one of the users has manually installed custom software to pretend to be a key, and is using that instead of their actual key for some reason despite being told not to by policy, and we take control of their machine then we can break in that way" is a massive difference.

Passwordless authentication with FIDO2—beyond just the web

farnz — Thu, 23 Feb 2023 13:57:58 +0000

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

mss — Thu, 23 Feb 2023 13:04:46 +0000

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

mss — Thu, 23 Feb 2023 13:04:23 +0000

So in practice you can buy the cheapest possible Android phone without a SIM card, install an OpenSource build there and it would meet your requirements.

This would still need some bootloader work though, to actually disable these network devices in a way that they cannot be re-enabled by the ordinary software stack without explicit user intervention - assuming that the hardware even has such "disable until reset" functionality.

Or opening the device and disconnecting their antennas - might be easier to achieve but harder to temporarily revert. And not easily doable for PCB antennas on the main board.

Another option would be to use a phone with hardware radio kill switches, like a PinePhone - but that technically isn't an Andorid phone, nor is it particularly cheap.

Passwordless authentication with FIDO2—beyond just the web

farnz — Thu, 23 Feb 2023 10:39:35 +0000

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

erwaelde — Thu, 23 Feb 2023 07:22:06 +0000

"Various manufacturers have built such hardware tokens. "

For increased nerd factor, the precursor by bunnie is such a thing, too:
https://www.bunniestudios.com/blog/?p=5921
https://www.crowdsupply.com/sutajio-kosagi/precursor

Cheers!

Passwordless authentication with FIDO2—beyond just the web

pabs — Thu, 23 Feb 2023 06:28:05 +0000

I definitely would not use Android for this, better would be a more minimal Linux distro that you control.

Passwordless authentication with FIDO2—beyond just the web

Cyberax — Thu, 23 Feb 2023 06:19:08 +0000

I'm not sure it's an improvement in security, though. I think right now USB on Android is kinda all-or-nothing strategy. Either you use it only for charging, or open the floodgates.

But I haven't checked this in a while, I might be lying.

Passwordless authentication with FIDO2—beyond just the web

pabs — Thu, 23 Feb 2023 06:10:50 +0000

You could drop BLE too, just use USB.

Passwordless authentication with FIDO2—beyond just the web

gdt — Thu, 23 Feb 2023 01:44:29 +0000

The strength of a Security Key for authentication integrity is the Secure Attestation Key. That demonstrates that a human is present, and that can't be undermined by a program on the intermediate laptop between the key and the server.

If the server allow keys from all claimed manufacturers, then the server also allows a program on the laptop, and the SAK is no longer unfakeable.

So whilst you may trust your key more, the server will need to trust your homebuilt key less. Unless the server trusts you enough to add your homebuilt keys' PKI root.

Passwordless authentication with FIDO2—beyond just the web

tialaramex — Thu, 23 Feb 2023 01:28:54 +0000

Just say "No" then. It's one click in Firefox, as I understand it it's one click in Chrome, I couldn't speak to Safari. This is an optional feature, you aren't required to agree to have your authenticator tell the Relying Party who made it.

I always say "No" and my tokens have worked everywhere that claims to support them on the web. I'm sure if you want employee access to some corporate system it might insist on a Yubico product or whatever and so (even though I do own such products) I'd be rejected for saying "No" but this has never happened to me on a public system in years of using them.

Passwordless authentication with FIDO2—beyond just the web

tialaramex — Thu, 23 Feb 2023 01:18:14 +0000

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

Cyberax — Wed, 22 Feb 2023 18:03:43 +0000

> But if there's a way to just reuse the basic hardware, disable cellular modem, WiFi, Bluetooth, USB network connectivity, ADB, etc. in a way that they cannot be re-enabled without explicit user intervention then it would mostly do the trick.

You need BLE (and maybe the phone camera) for passkeys. Everything else can be disabled.

So in practice you can buy the cheapest possible Android phone without a SIM card, install an OpenSource build there and it would meet your requirements.

Passwordless authentication with FIDO2—beyond just the web

NYKevin — Wed, 22 Feb 2023 17:37:48 +0000

To my understanding, this is mostly used in two contexts:

1. Employers, who IMHO do have a right to say "you may not use some random key, you MUST use the key that we provide."
2. Various forms of "compliance," which is usually just a special case of (1), but occasionally does show up for consumer accounts in e.g. banking or healthcare.

Unfortunately, we live in a world where you can buy a 10+ TiB SSD from Amazon for $100 USD, and (shockingly) it turns out to be a fake,* so I don't think the institutions who are doing (2) really have much of a choice. It would be too easy for a braindead-but-cheap implementation to become popular.

* See https://www.google.com/search?q=those+fake+cheap+ssds+on+...

Passwordless authentication with FIDO2—beyond just the web

NYKevin — Wed, 22 Feb 2023 17:24:02 +0000

> and AFAIK such OS-level WebAuthn subsystem doesn't exist yet (at least not on Linux).

It doesn't exist on Linux because Linux does not have a coherent "how does the GUI work, and which bits of it are considered [waves hands] the OS?" story. On Windows and macOS, this sort of thing is entirely standard.

Passwordless authentication with FIDO2—beyond just the web

wsy — Wed, 22 Feb 2023 15:44:48 +0000

My problem with FIDO2 is that service providers may choose to only allow hardware modules from certain vendors, making self-built keys unusable. I trust myself more than any hardware vendors.

Passwordless authentication with FIDO2—beyond just the web

smurf — Wed, 22 Feb 2023 14:40:55 +0000

Using a phone raises all those fun security concerns that prompted us to switch to Fido2 sticks in the first place.

So, cute that it's possible, but when it enables the same security problems 2-factor auth is supposed to fix, probably not a good idea.

Passwordless authentication with FIDO2—beyond just the web

Conan_Kudo — Wed, 22 Feb 2023 13:57:26 +0000

Nobody would use that. I certainly would not. BLE with a secure enclave trigger through biometrics or a passphrase is more than enough for me.

Passwordless authentication with FIDO2—beyond just the web

mss — Wed, 22 Feb 2023 13:44:02 +0000

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

mss — Wed, 22 Feb 2023 13:38:00 +0000

Using a Linux phone as a hardware base for such authenticator token might by a good idea, just not a stock one running full network-connected OS.

Having only simple interface to the rest of the world, which has a limited attack surface and is relatively easy to audit, is the whole point of a hardware token.
I think that any kind of network connectivity would weaken it to the point of almost defeating its purpose.

But if there's a way to just reuse the basic hardware, disable cellular modem, WiFi, Bluetooth, USB network connectivity, ADB, etc. in a way that they cannot be re-enabled without explicit user intervention then it would mostly do the trick.

The device could work line this:

The system is powered on or restarted
The early boot code checks for certain unusual combination of buttons (or does some other robust user presence/will check)
If the above check fails the code locks its flash partition read-only (so the boot code can't be overwritten) and permanently disables network interfaces for the session
The main authenticator software stack starts

Then any potential network-related attack surface would be limited only to that tiny chunk of early boot code.

In this case the device itself only needs a minimum kernel that exports just a FIDO2 HID gadget interface over USB to its host and provides basic authenticator GUI.

Passwordless authentication with FIDO2—beyond just the web

tialaramex — Wed, 22 Feb 2023 11:50:38 +0000

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

Conan_Kudo — Wed, 22 Feb 2023 11:42:29 +0000

You can also use Web Authentication caBLE v2 to do this over Bluetooth Low Energy. Chromium implements this for supporting your Android phone as a FIDO2/WebAuthn passkey.

Passwordless authentication with FIDO2—beyond just the web

MortenSickel — Wed, 22 Feb 2023 09:58:48 +0000

"Are there any other countries using a standardized online banking protocol?"

In Norway, we have the bankid system (https://www.bankid.no/en/private/) that is used for more or less all banks and a lot of other places where a secure login is needed. It can be used either by a code generator or a mobile phone app - no plugin devices.

Passwordless authentication with FIDO2—beyond just the web

djm — Wed, 22 Feb 2023 07:44:01 +0000

OpenSSH never supported SRP, though there were third-party patches. The whole protocol was IIRC under a patent cloud for a while.

Passwordless authentication with FIDO2—beyond just the web

Cyberax — Wed, 22 Feb 2023 05:40:18 +0000

> Such OS-level protection would need to also need involve things like X11 server or Wayland compositor to make sure that the authentication prompt dialog box isn't simply painted over with a fake one or quickly accepted by a fake input event.

It's not possible with X11, but Wayland already does this. A Wayland client such as a browser doesn't have access to other clients, including the daemon process that handles the FIDO2 events.

The browser will need to be additionally confined to disallow it access to other stuff. But it already should be mandatory. And it's already the case with Android and iOS.

> All this effort would at best move the required threat just one level-up - now a "root" account or kernel compromise would also be necessary, so it wouldn't be a qualitative change.

Well, just use your phone over Bluetooth for the FIDO2 device. This way you'll know exactly which website is requesting the auth: https://github.com/fmeum/WearAuthn - I believe this will soon be available on stock Android as an OS-level service with hardware-based security.

Even in the absence of this, there is still at least some bit of security because you need physical interaction with the FIDO2 device (touching a button) that can't be faked even with the compromised kernel.

Passwordless authentication with FIDO2—beyond just the web

matthias — Wed, 22 Feb 2023 04:32:28 +0000

> How would you protect against a threat model where the browser or os are compromised at this level? A display on the device? Would people read it?

Yes, a display on the device. Just in the same way, as I do online banking in Germany. A display shows the account number and amount for an authorized transfer. Doing this with something like FIDO2 would be much nicer than with the devices we currently use, where we have to put in the banking card to do the encryption, then scan the transaction details from the screen*, and afterwards type in a transaction number from the devices screen into the banking website.

And I do actually read this. For small amounts I usually only check the amount, as the possible damage is limited to the amount shown on the display. For large transactions, I also verify the account number.

*newer devices use QR-codes. My device has 5 photo-diodes that scan a flickering code. One of the diodes is used for a clock signal, the other 4 to transfer 4 bits in each clock cycle. A really simple device. All actual cryptography is done inside the banking card and the device only transfers data from the computer screen to the card and the builtin display.

Passwordless authentication with FIDO2—beyond just the web

pabs — Wed, 22 Feb 2023 03:38:24 +0000

There are a few projects that could lead to OS-level WebAuthn/passkeys.

https://github.com/bulwarkid/virtual-fido
https://github.com/psanford/tpm-fido
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/fido...
https://news.ycombinator.com/item?id=33943008