How are these private keys being stored? It seems to be implied that there is a different public/private key pair for every website so are they stored in the browser? (or at an OS-level?)
In a hardware token, there's generally a single master secret and private keys are derived on the fly for each website you register/log into. So you can use 1 single hardware token with an unlimited number of sites (note that you prob want to register at least 2 tokens per site, in case you loose one, but this is a different story).
The standard also define the concept of resident keys (RKs), that you can use for passwordless authentication (typically with a PIN on the token, to avoid theft). In this case of course each key consumes a bit of storage, so the number of sites is limited. For example, a Solo key can currently store 50 resident keys. To the best of my knowledge, apart from demo sites, the only "real" site supporting resident keys is microsoft/outlook.com, so this is currently not a real practical limitation.
They are stored on hardware tokens. There does not seem to be a way to have privately generated software keys, nothing like putty's pageant or .ssh/authorized_keys.
WebAuthn seems to be designed by big businesses to take control of the authentication ecosystem.
Not necessarily: the WebAuthn spec mentions two other types of authenticators in the introduction section (https://www.w3.org/TR/webauthn-1/#intro):
"Broadly, compliant authenticators protect public key credentials, and interact with user agents to implement the Web Authentication API. Implementing compliant authenticators is possible in software executing (a) on a general-purpose computing device, (b) on an on-device Secure Execution Environment, Trusted Platform Module (TPM), or a Secure Element (SE), or (c) off device."
> There does not seem to be a way to have privately generated software keys
A specification is something different than an implementation. On https://github.com/herrjemand/awesome-webauthn you'll find (at the time of writing) two software implementations. https://krypt.co/ can be a third if you want to consider a U2F implementation as well.
The section https://github.com/herrjemand/awesome-webauthn#software-auth... talks about using Android phones or Wear OS to webauthn with Bluetooth. The section title is misleading. It's not about software tokens, but about turning one's phone or a smart watch into a hardware token.
The section title is correct: they're authenticators implemented in software, not relying on a TEE/TPM or any other bit of hardware for storing the keys. Apparently these don't run on on your CPU architecture and/or operating system of choice, but that's another issue. The claim of "they are stored on hardware tokens, there does not seem to be a way to have privately generated software keys" is incorrect.
If you are looking for a solution that supports FIDO2 and also functions as a hardware password manager (lots of sites still don't even support security keys) check out OnlyKey - https://onlykey.io/
OnlyKey is also open source here are some of the features:
- On device PIN
- FIDO2 (15 Resident keys)
- TOTP (24 accounts)
- Static passwords (24 passwords up to 56 char long)
- OpenPGP
SoloKeys person here ;) You can implement software authenticators (listening on local USB port), I imagine some password manager people will do so eventually, or have a direct way to hook into requests. Krypton did this for U2F.
Hardware keys are for if you want hardware security, obviously they can't be free unless you want someone with a different business model to subsidise them.
Yes software authenticators that use a security key for OTP are a good option. This is what Yubikey does with the Yubikey Authenticator. As with most security things there are tradeoffs to each approach. The pro of a software authenticator is that you can have an unlimited number of accounts, the con is that it requires the user to install an app on their phone/computer (in some cases the OTP shows up in a desktop app it may be possible for hacker to intercept). With the OTPs being generated and typed by the key itself the pro is that you don't have to install an app and login can be faster because the OTP is typed for you, no reading and typing it manually (also harder to phish). The con being you can't store unlimited accounts and since the key is typing the OTP the key has to be physically connected to a phone/computer.
Listening to local USB port? Hm... Why should I listen to a local USB port to exchange keys in a PKI? This only proves my point that WebAuthn is about hardware replacing passwords.
There is no way to generate your own software key pair as easily as one can do with ssh-keygen.
The whole spec is designed with hardware tokens in mind, software tokens are not mentioned anywhere, and WebAuthn spec designers wave their hands when asked about software tokens.
You can just implement the client in software and use it if you want, the protocol doesn't care. Firefox already ships with that functionality and you can enable it.
The point is that ssh keys lying around on your laptop aren't the greatest idea either. Where is the root of trust? The password you type to terminal if you encrypt them?
FIDO2 starts with the idea of safe defaults, where either client devices (Android, laptop TPM,...) store the keys safely, or dongle vendors (like us, SoloKeys). These have a business interest in doing their job properly.
But there's nothing preventing software implementations, it's an open standard in that respect (I do have other issues with it but your specific concern is unfounded imho).
As Stavros mentions, you can, and if you feel qualified, you should manage your own keys. Be that with some software authenticator you deem safe or write yourself, or with e.g. our keys that are open source, so you can modify anything to your liking, etc. etc.
I sense a bit of 90s security thinking from your arguments though, where every end user and mid-level admin handles security decisions they're frankly not qualified for.
This is what I meant by "safe defaults". Yes some people use e.g. password managers, but no, most people don't. Yes, some people manage to use GPG to manage their ssh keys, but no most people, even qualified, don't/can't/won't.
"Bad defaults with patches hopefully making it safe" is just not the way we should be heading.
I agree with all of your points, I'd just like to point out that, even if everyone ends up using software authenticators (password manager-style) with WebAuthn, we'll still be in a much better position than we are today, where people just use the same insecure password everywhere.
Well, that's assuming that the anti-feature of device attestation doesn't end up being used in the inevitable way that the spec allows:
"But attestation is not spoofable. Therefore, if sites launch webauthn support and accept attestations from the current set of token vendors, future vendors may be locked out of the market: Their devices won’t work because their attestations aren’t trusted, and they won’t be able to get sites to update because they won’t have enough market presence to matter."
I think the whole attestation thing is generally a terrible idea. It's not impossible to extract data from secure hardware, right now there is not a lot of incentive to do it because it's not going to get you much, spend a month of hardware research to get one user's key, no thanks. But with whole batches of devices having the same private attestation key stored on the device this incentives essentially ransom of security key vendors. I.e. Lets say I am a hacker that spends a month of hardware research finding a vulnerability and extracting the attestation private from a token. Its worth my time because I know this vendor has 100,000+ keys out there that uses this same attestation key. I then request that vendor send me $500,000 in bitcoin or I release the private publicly. The vendor pays the ransom because it's cheaper than recalling 100,000+ security keys. Another issue here is it's not if but when this happens, so when it does how do all of the web sites out there update to block the hacked keys? Lots of web sites never will. Time to rethink the attestation key being stored each token, that's a bad idea.
I hope that principle does establish itself among users of the web, but I suspect that if a bank says "You have to use one of these supported devices to access your account online" people are not going to change their bank because of it.
Similarly, if China mandates a government-approved (backdoored?) device when accessing Chinese websites, I don't suppose Chinese citizens are going to boycott those. Other countries might reasonably retaliate by forbidding sites to accept authentication by devices made in China.
Do you think that if Apple decreed that you can only securely log in to Apple websites with an iPhone (or some other device made by Apple) people would switch to Android? It's hard enough to get people to boycott Facebook despite repeated scandals that are much worse than having a whitelist of supported authentication devices.
If those organizations wanted to do what you say, and WebAuthn didn't support attestation, I doubt they'd say "well I guess we just can't do that" and give up, though.
Right now they can't (cheaply) say "You must own a device from this specific list in order to use our website" because there is no way of cryptographically proving that. What WebAuthn has done, by including support for attestation, is make that not only possible but likely, presenting it as something beneficial for security and making it easy to implement.
It is rational to not give your adversaries the tools needed to oppress you.
I don't agree. My bank issues its own hardware tokens that I must use, China mandates the use of its equipment and Apple does the same. If someone wants to mandate the use of a specific device, they can just do that. The fact that a similar standard exists doesn't mean much.
If my bank wanted to mandate the use of Yubikeys, it would do that, WebAuthn or no. It would sell me the Yubikey, as it now sells me its RSA token. I don't think the protocol the token speaks matters.
You started by saying that if a service required a specific type of hardware to use it then we should boycott it, but now you're saying it happens all the time and you're fine with it.
I accept your point about the protocol being irrelevant, however. One could even say that, if services are going to require specific pieces of hardware, it makes sense that the requirements are communicated and enforced using an open standard protocol, as that does allow a certain degree of interoperability and Free Software implementation.
The counter-argument, though, is that currently there are barriers to sites implementing such policies (due to the cost of issuing these devices and linking them to a specific account/address). If we set the precedent that every site should be using this technology, and reduce the cost of doing so, we bring about a set of dynamics where individual sites can start to introduce incompatibilities, whether with good intentions, or for anti-competitive reasons, or by accident.
Maybe this won't lead to people needing to carry around five dongles and two phones with them, but it could easily lead to having a lot of power concentrated into the hands of a small number of entities, or even just a single one, like the bad old days of "This site works best in Internet Explorer". Moreover, this is not just a theoretical concern, as it has already started to happen, as the link above explained:
"FIDO does not dismiss these worries and their answer, for the moment, is the metadata service (MDS). Essentially this is a unified root store that all sites checking attestation are supposed to use and update from."
