WebAuthn, and Only WebAuthn
blog.mailpace.com
blog.mailpace.com
You could also use the system TPM (https://github.com/psanford/tpm-fido).
A brief search didn't yield any FIDO2 software-only solutions for Linux, but I see no reason why in principle you couldn't implement it (perhaps interfacing https://github.com/google/OpenSK through hidg - similar projects do exist for U2F).
Still, if compared to a local software TOTP, it's not necessarily a step down.
A software WebAuthn solution stops the most common threat that TOTP misses: phishing.
Even software WebAuthn is better security than TOTP in every way, especially if it takes the QubesOS approach of running it in a dedicated offline VM.
If we keep allowing the use of inferior options, Webauthn won’t gain traction.
Chromium also has built in virtual webauthn support in devtools and other examples like this already exist: https://github.com/bodik/soft-webauthn
The goal of 2FA is not to stop malware, as malware on your machine will just take the post login cookies and do whatever. The point of 2FA is to protect a user from phishing or database leaks, and TOTP fundamentally fails at stopping both. You can also change system time and get a valid token in the future, and anyone with read access to your phones or the servers system memory can get unlimited free codes by dumping the plaintext secret.
Any service still offering TOTP is frankly negligent. WebAuthn is the only standard phishing resistant 2FA available and even pure software emulated solutions offer dramatically better protection than TOTP.
Why not go full passwordless, with a fido2 token + pincode? It's more secure and you need the token anyway. No password to remember or for an adversary to guess. Even the account can be derived from the token. With Office 365 all I have to do is insert the token, enter the pin, touch it (to avoid remote control abuse) and I'm logged in.
Simple as taking money out of the ATM and just as secure.
(password and phoneNumber) or token
might be harder to explain than
password and oneOf(token, phone, etc)
Plus they'd have to probably change a lot of code, for not thar much demand, everyone just lets the browser remember passwords.
And what you describe "password and oneOf(token, phone, etc)" is not how passwordles works. It is really just "oneOf(token, phone, etc)". The token itself is what validates your PIN code in this scenario.
Eventually they'll have to implement this anyway because it's the "end game" for the FIDO designers. And it's something the competition already offers: https://docs.microsoft.com/en-us/azure/active-directory/auth...
I would not be happy if I suddenly had to by several of these tokens, carry them around, and potentially manually swap them out, since many current ones only hold 25 keys or so.
I wonder if something simpler wouldn't be possible, that didn't involve storing keys on-chip, or storing them in encrypted form on the host.
Couldn't the token just generate the key as needed, seeded by hash(domainName, accountName, salt, internalSecret)?
It seems like YubiKey does something like this but some seem to actually store keys, or require some complex in browser or server side storage, adding points of failure.
And there seems to be some "resident key" feature that always stores data on the authenticator? Is that really necessary?
This is not how FIDO2 works. It uses the same key but it generates a different derivative for every site. There is no limit on how many sites you can use it on. And the derivative is different for each site, so you can't hijack an authentication session and use it for another site. It's pretty well designed.
> I wonder if something simpler wouldn't be possible, that didn't involve storing keys on-chip, or storing them in encrypted form on the host.
It is possible, but this is a weakness because you have the key in more than one place. Having it only inside the token is what makes the token unique. But Apple and Google are working on something like this: https://news.ycombinator.com/item?id=31272867
But personally I prefer the physical keys. And no it doesn't require browser storage.