I haven't found any so far. Each account gets a new public/private key pair so accounts can't be traced back to each other. Usernames are optional and might even become a thing or the past, making username reuse less of an issue for linking accounts.
It all depends on the sync method provided. If synchronisation isn't end-to-end protected, you're handing Apple/Google/Microsoft the keys to the kingdom which is pretty bad.
FIDO2 privacy is actually pretty good and well thought out. There's a theoretical risk of a website sending authentication challenges for two different accounts and having both assertions signed by the same credential, basically correlating those accounts together, but this is unlikely to weaken collective privacy at scale.
Kind of. Yubikeys intentionally have a very small number of devices signed with one CA key and then they produce a new CA key, so those devices do have a basically unique identifier.
The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked.
Also, the Alliance could decide to blacklist a manufacturer just because they haven't implemented some new policy (like requiring a DNA scan of the user) so you better make sure that you buy a device from one of the "too big to fail" providers.
> The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked.
1. By what mechanism can they blacklist a device? A given relying party can choose to use or not use attestation and, if they choose to use it, which certificates to trust. But that's between you and the RP. Authentication doesn't "talk to" the FIDO Alliance--which is just a standards body and does not (AFAIK) even publish anything like a CRL for "bad" attestation keys, so I don't understand what you are talking about here.
2. The intention of the attestation, as I understand it, is to enable RPs to use attestation to limit authenticators to e.g. those that pass FIPS certification (or similar enterprisey requirements), not to ban a whole batch because one key is known to be compromised. That's crazy; can you point out where anyone other than you has ever proposed this?
3. DNA scan? What are you talking about?
4. This assertion you are making, while bizarre and wrong, is very different than the assertion the grandparent made ("Yubikeys intentionally have a very small number of devices signed with one CA key...so those devices do have a basically unique identifier"), which, while also wrong, is I think a genuine mistake and not a bad-faith argument.
> A given relying party can choose to use or not use attestation and, if they choose to use it, which certificates to trust.
True, and a website could decide to issue its own certificates rather than get one from a CA trusted by browsers, but in practice (and potentially one day by law) most sites will defer to the FIDO Alliance to determine which devices are "sufficiently secure".
> the FIDO Alliance--which is just a standards body and does not (AFAIK) even publish anything like a CRL for "bad" attestation keys
"The FIDO Alliance Metadata Service (MDS) is a centralized repository of the Metadata Statement that is used by the relying parties to validate authenticator attestation and prove the genuineness of the device model."[0]
> That's crazy; can you point out where anyone other than you has ever proposed this?
"If the private ECDAA attestation key sk of an authenticator has been leaked, it can be revoked by adding its value to a RogueList."[1]
> DNA scan? What are you talking about?
I picked a deliberately extreme example to make the point that there are requirements for these devices that users might not be happy with (but might not have any choice about, once the capability becomes ubiquitous). That specific example may never come to pass, but I don't think we should assume that allowing RPs to put arbitrary conditions on the hardware we use is a power that won't be abused.
For added context: "FIDO will soon be launching a biometric certification program that ensures biometrics correctly verify users. Both certifications show up as metadata about the authenticator, providing more information to enable services to establish stronger trust in the authenticators.)"[2]
> This assertion you are making, while bizarre and wrong ... a bad-faith argument.
> True, and a website could decide to issue its own certificates rather than get one from a CA trusted by browsers…
That’s quite different. In your example, if a website does so unilaterally, client user agents break. In the FIDO case, nobody else knows or cares which authenticators an RP trusts.
More broadly, I don’t get this conspiracy theory. You’re worried…the FIDO alliance will abuse their very limited power to…what end?
> If the private ECDAA attestation key sk of an authenticator has been leaked, it can be revoked by adding its value to a RogueList."[1]
The attestation key, which is shared among all devices? That’s rather different from what you said.
> That specific example may never come to pass, but I don't think we should assume that allowing RPs to put arbitrary conditions on the hardware we use is a power that won't be abused.
RPs already have such power. Today they use it to do things like require password complexity policies. Again, RPs aren’t the FIDO alliance; they’re the actual website you’re logging into.
Your repeated argument here is that websites should not be allowed to impose restrictions on how their users authenticate, which is hard to fathom.
In a previous version of this argument, I remember you essentially arguing that banks and enterprises should not be able to restrict what types of authenticators their employees and customers use.
I get it. You hate attestation. But “my employees must use a fips-certified key” (or “my customers must use a hardware key”) is reasonable and ultimately non-negotiable if you want people to use your protocol.
> But “my employees must use a fips-certified key” (or “my customers must use a hardware key”) is reasonable and ultimately non-negotiable if you want people to use your protocol.
I think this is the crux of where our disagreement lies. I grudgingly accept that FIDO makes it easier for companies to check that their employees are storing their keys on company-approved devices, but I don't think that arbitrary websites should be given the power to make demands about the hardware that visitors must use to create accounts. That seems like a worse position for user freedom than we have today with passwords.
You might say that websites already have this power, in some convoluted way. They could say "Enter your credit card details and postal address here and we'll send you a custom device you can use to log in to our website", but in practice no company does that. (Banks and governments are maybe special cases, and less concerning given that: their authenticators are managed out of band; they are highly regulated; they usually have actual branches that you can go to in person to sort things out; and people generally choose to interact with banks/governments that are based in their own country).
Attestation changes the market dynamics here. Suddenly it becomes acceptable for sites to bully users into buying certain types of devices, and for governments to start demanding that these devices be used as online IDs (at least for age verification, to start with). Even if companies don't abuse this power to keep people in their ecosystem (e.g. Apple sites giving you special features if you log in with an Apple device), the first casualties are going to be open source hardware and software implementations, which will be deemed insecure, and further normalise the idea that users can't go online without running proprietary code.
Yet Google, one of the key participants in the FIDO alliance, has published an open source firmware!
I agree the potential exists, in a hypothetical sense. But the dynamics are very different than you describe (with your analogy to the CA ecosystem, which, ironically, gives big platform owners far more power—yet has no evidence of such abuse!).
Right now, there is just not that much use of WebAuthn and FIDO. You’re the guy saying, “if we find a way to lower global temperatures, we should fear an ice age.” It’s premature to say the least.
I'm glad Google has published an open source firmware, and I hope that people will be able to independently verify that the hardware they use is genuinely running that firmware. Then I hope that hardware with such guarantees is not discriminated against by RPs.
The important difference with the CA ecosystem is that (in the worst case) the big platform owners can put pressure on small websites to obtain a certificate from one of a large number of competing issuers. Significantly, these issuers are not the same as the big OS providers themselves, and there are issuers who issue certificates for free. That is completely the reverse of 3 big platforms forcing end users to buy hardware, and those platforms being hardware vendors themselves.
> You’re the guy saying, “if we find a way to lower global temperatures, we should fear an ice age.”
No, I'm the frog saying "Hey, isn't this water getting a bit warm? Don't you think we should jump out before it's too late?"
But the big three can't do that, with FIDO. All they can do is influence the FIDO Alliance to add other SK manufacturers to the pseudo-CRL, which:
- is transparent
- is mediated by the FIDO Alliance; the platform makers cannot do it unilaterally, as they can with CAs in browsers
- is mediated by the RPs; even if the FIDO Alliance did do this for some reason, RPs could just ignore it with no ill effects, unlike with CA trust in browsers
- wouldn't have any effect today for the vast majority of RPs, since the vast majority do not even use attestation today
- honestly, isn't something they have any incentive to do; hardware security keys are not a meaningful source of revenue for someone like Apple, Microsoft, or Google
I'm guessing you've never worked in a big tech company before if you think they have an incentive to do that. :)
Not a great thing to see the big three once again, driving the standards here. You should be worried.
But as long as the ridiculous SMS 2FA is removed or replaced by something better, then fine. But we'll see how this goes.
From the web side of this standard, this also tells me that Mozilla has no influence anywhere and will be the last ones to implement this standard in Firefox.
Both FIDO and W3C are neutral places for this. Mozilla being a part of W3C and FIDO will have a say. This is just a PR stunt that the tech journalists ate up. They’ve been working together to make this for the last two years, it’s just an announcement to accelerate the work on it.
Mozilla is a member (https://fidoalliance.org/members/), so I doubt they'll be the left to their own devices. They'll probably lack the manpower to implement the additions well (I mean, you can't even paste a URL to an IPv6 address in Firefox for Android, which is one of the most basic features of a browser), but then again they already have Firefox Sync and a working WebAuthn system.
This passwordless signin process sounds neat, but will it increase Google’s power to lock people out of things? I don’t understand why Google doesn’t have an ombudsman - consumers have no recourse when Google locks them out, and it seems the consequences of Google locking you out are ever increasing. I think we’re going to need legislation to force Google to make a proper appeals process.
At some point (unless you're an Android dev) you have to accept a bit of responsibility. If you use Gmail, Drive and Android and then decide to use Android as your preferred implementation of FIDO (when YubiKeys ect, exist) I struggle to see how if you're locked out it's not partially the consumer's fault.
You choose to use Google, and can attest to the fact it's not that difficult not to.
Google's power to lock people out of their website is already here with Oauth2.
This standard is unrelated; it works by having the browser/device itself sync the virtual security keys[0], much in the same way they sync passwords currently. That's the only thing changing here, giving people the choice (and encouraging them) to sign in via "what you have" instead of "what you know", but along with that they want to alleviate the UX concerns of people not being ready to carry around a separate physical security key.
> I don’t understand why Google doesn’t have an ombudsman - consumers have no recourse when Google locks them out
Coming soon to an EU country near you!
The EU digital markets act address this issue directly, by requiring “gatekeepers” to provide human customer response, and clear processes for appealing bans etc and generally forcing companies to provide something akin to due-process.
I hope this cross device system will be cross platform, but I wouldn't be surprised if you could only choose between macOS/iOS, Chrome/Chrome, or Edge/Edge sync.
Funnily enough, a system for signing web authentication requests from a mobile device is far from new: I've been using https://krypt.co/ for years (though it's on the long road of sunsetting right now) and I hope that will last long enough for the new cross device standard to replace it.
It won't, at least not in the short term. For that to happen trusted platform modules would need an api to export a private key wrapped with a certificate signed by (none/one/all/a quorum) of members in the circle of trust and itself. This will need standardizing. Only apple has implemented it so far because it has total control of their ecosystem. I think for Windows and Chrome to work like this, they'll need to start requiring TPM vendors to implement this in their drivers, but I can't see it being cross compatible with the API in the apple TPM any time soon, especially because the circle of trust is now as weak as the weakest TPM, and it's a reputation risk for apple if a credential gets compromised because some non-apple device trusted by the user in an apple circle of trust got breached
I think the first iteration of this system will definitely receive the synced key material in RAM.
It's possible that the TPM spec will be updated to allow for loading pre-encrypted data into the TPM store as a response to this. Alternatively, existing secure computing systems (SGX/TrustZone) can also be used to decrypt the synchronised key relatively securely.
receiving synced key material in RAM significantly alters the threat model. Apple's current passkey implementation does not, at any point, handle unwrapped key material in the operating system. I expect all other implementations to follow.
TPMs don't generally store encrypted data (bar their master key)
instead they wrap/seal everything instead with a layer of crypto, then you can pass that wrapped object around as much as you want, only the TPM can unseal it
a TPM could easily be instructed to seal an internally generated secret with additional escrow keys for MS/Apple/...
that plus remote attestation could make it so you can never see the key in the clear
As far as my understanding goes this sealed secret is device specific and connected to the TPM master key. That would mean you could pass it around, but you'd need to have the blob on the device itself to actually use it.
The problem is that you need private/public key pairs that are synchronised across devices for FIDO to work properly cross-device. When you register an account on your phone, you need that account key on your desktop to use it there, and that's nearly impossible without some kind of key sharing mechanism.
Yes but what the OP is saying is that the TPM does not store the encrypted passkey, rather, the passkey is wrapped with this TPM's public key by another TPM that already trusts this TPM, so this TPM can import a passkey that's been wrapped with its own public key and store it unencrypted. See Apple's circle of trust: https://support.apple.com/guide/security/secure-keychain-syn...
I understand that, but that's not supported by any current standard as far as I know. We'll need a new TPM standard for this, which probably also means it will take years before every device supports this feature as modern computers can easily last five to seven years if you replace the batteries and don't cheap out. FIDO needs something that works now, or maybe tomorrow.
Agreed, and that's why I say in my original comment that I don't see it happening in the short term. If we had something that worked now or maybe tomorrow and was acceptable, it would simply be virtual authenticators; an authenticator implemented entirely in software. There's no practical reason why password managers like 1Password can't do that beyond attestation which nobody checks anyway. But in the end, I don't see the big three participating in sharing. The threat model changes so much that especially for Microsoft (in cell phones) and Google (in desktops) that means trusting an adversarial OS they have no control over
So their vision of the future is that to do anything online, one MUST have a phone (ahem, portable wiretap)? And they're going to be keeping my secrets for me, for my own good?
I doubt they'll do away with tools like smart cards or Yubikeys any time soon. Laptops and modern computers also contains a TPM so you don't necessarily need to have a phone for secrets storage.
If push comes to shove, I'm sure someone will develop a lightweight Android emulation layer you can run in the cloud that pretends to be a phone enough that you can use it.
> Laptops and modern computers also contains a TPM
The root of trust for which extends to who knows where, and you're not allowed to look at the source code or learn how it works because that would threaten Hollywood's profit margins.
We're basically building a system of DRM for access to human beings, and making the whole world dependent on these unaccountable entities.
TPMs allow for arbitrary key storage by the operating system. They're not necessary for DRM. In fact, I've wiped my TPM several times to upgrade the firmware and I've had no trouble playing DRM content whatsoever.
Technologies like Intel's management engine and SGX or their AMD/Qualcom/Apple counterparts are definitely problematic for user freedom in the way they're implemented. However, the TPM system itself is quite neutral: usually, you can clear it from the UEFI, lock it with a password (though that might need to be done from the OS) leaving whatever hostile OS you may run unable to exert any control on the device whatsoever.
I'm personally a big fan of technologies like TPMs and secure boot as long as they're user configurable. I want to be able to install my own keys and force the system to only boot operating systems of my choice. Secure boot with just the MS keys is quite silly and ever since that one version of Grub could be exploited it's basically useless; secure boot with user or enterprise keys can be an incredible tool for defence in depth, for example when visiting countries where border agents may try to gain access to your data without your permission or knowledge (China, USA, etc.).
If I had my way, I'd use Coreboot together with Secure Boot, with encryption keys stored in a TPM, the transfer of which goes through an encrypted channel (a feature of TPM 2.0 that nobody uses) after unlocking it with a password. Sadly, most Linux OS developers have a grudge against these technologies because they're used by companies such as Microsoft and Apple to reduce user freedom on some of their devices.
Is there a way to list this blacklist? I have several computers which haven't received updates in years and I strongly doubt that the internal blacklist has been updated.
The user-hostile part of the TPM is the built-in key signed by the manufacturer which shows that it's an "approved" TPM which won't—for example—release any of the keys stored inside to the device's owner. This is what allows the TPM to be used as part of a DRM scheme.
If it weren't for that small detail then I would agree that TPMs can be useful for secure key storage and the like, working for the device's owner and not against them. The actually useful (to the owner) parts of the TPM do not require the manufacturer's signature.
It enables it, but that's just because both you, the device user, and M$ and the rest of the media industry, need to ensure the TPM inside the processor is genuinely from the manufacturer. You wouldn't want to use a TPM if an attack vector is one where China (who is a large part of the supply chain) can poison a large amount of TPM shipments with their own key that can be used to export or otherwise access internally-stored keys.
If your threat model is "China has backdoored your TPM" then making the TPM more opaque and unauditable doesn't improve the situation. How would you know if your TPM is lying and pretending to still have the original key when actually it has a replacement Chinese one?
The actual attestation process protects against this:
program generates random bytes->ask tpm to sign it->on signature return, program asks TPM for its public key->program verifies public key matches that of the signature->verify the public key is cross-signed by the manufacturer's certificate authority. The only attack here would be if Intel or AMD's PKI is compromised, which would certainly be leveraged against enterprise customers before any consumer customers got hit.
With regard to supply-chain attacks, since the TPMs are manufactured in China, they can just make a perfectly "genuine" TPM with a valid, signed key which has their backdoor. The attestation process protects DRM users (media companies) from device owners. It doesn't protect device owners from TPM manufacturers.
As I said—manufactured in China. Both the government of mainland China and the government of the Republic of China (Taiwan) consider mainland China and Taiwan to be parts of the same country. They only differ with regard to who is in charge.
The issue could be addressed without removing the ability to attest as to the TPM's origin by including a protocol for the owner to dump the device's private encryption keys (e.g. by shorting one of the external pins to ground). The fixed attestation key set by the manufacturer would need to be restricted so that it can only be used to sign attestation messages, with all other keys being generated on the device so that they can be reset when the device changes owners.
Which is a pretty big security threat that is constantly ignored. It just isn't acknowledged when people talk positively about TPM even if remote attestation is completely build-in by now. Security for whom becomes the question here.
My vision of future authentication (shared by colleagues in security) is based in strong hardware credentials and additional layer-7 context about identity, device and location. Basically, more identification of you and your browser using cryptographically-guaranteed and immutable events. It is actually the deprecation of passwords altogether and generally moving the trust boundary away from the control of the user entirely. I also don't enjoy it, but it would solve a lot of current problems we see in information security.
Every technology is a double-edged sword. Like firearms, security controls can be used to guarantee peace and freedom or wage war and distress. The responsibility is with the administrator of that tool, not the tool itself.
I don't know if you're being sarcastic, but your vision sounds like a nightmare and not very far removed from Gattaca.
> moving the trust boundary away from the control of the user entirely. I also don't enjoy it, but it would solve a lot of current problems we see in information security.
Every despot throughout history has noted that freedom can be traded for security, but I thought that most of us would agree that freedom is more important.
Society is replete with trade-offs sacrificing freedom for collective security. You can make moral judgements about this all day, but it won't change the dynamics of our lives.
Doesn’t require phone? Supported by desktop browsers also. Third party “auth managers” should be possible — likely integrated into existing password managers?
It's literally the opposite. You "must" have a cryptographic device (a dongle) that is only doing that one thing, authentication. Doesn't have a built in radio (unless for NFC, if you want it), doesn't have any microphone or camera, doesn't store any data beyond what's needed to authenticate, doesn't communicate except to authenticate - bi-directionally, so phishing is no longer a thing, or at least it's a lot harder.
It's very hard to make a privacy case against FIDO. Practically speaking it's one of the best things that happened to privacy&security since the invention of asymmetric cryptography. The deployment of this tech reduces phishing effectiveness to near zero, or in many cases literally zero.
> It's very hard to make a privacy case against FIDO.
With username and password, I have full control over my privacy in a very easy to understand fashion: If I randomly generate them I know I cannot be tracked (as long as I ensure my browser doesn't allow it by other means).
With those keys I have a opaque piece of hardware which transfers an opaque set of data to each website I use and I have NO idea what data that is because I do not manually type it in. I need to trust the hardware.
Sure, I could read the standard, but it very likely is complex enough that it is impossible to understand and trust for someone who has no crypto background.
And I also have no guarantee that the hardware obeys the standard. It might violate it in a way which makes tracking possible. Which is rather likely, because why else would big tech companies push this if it didn't benefit them in some way?
> Which is rather likely, because why else would big tech companies push this if it didn't benefit them in some way?
They switched to this internally a long time ago which basically eliminated phishing attacks against employees. There are security teams inside those megacorps that have a general objective of reducing the number of account takeovers, and non trivial resources to accomplish that. Not everything is a conspiracy.
Also, I am sure you will be able to stick to just passwords for a pretty long time while the world moves on to cryptographic authentication. I'm not being sarcastic here.
Yes, they also track the behavior of their employees. It is security for them and not for the user in many cases. In a perfect world those incentives align but they don't have to.
With your password manager, you're trusting a lot more: the software of the OS and kernel, the software of the browser and its dependencies, the software of your password generator and your password storage. You also have to hope the developers and administrators of the website you're signing in to aren't storing your passwords in plain text (and I don't just mean in the database - overly-aggressive APM/logging might be storing POST request data in a log stream somewhere).
The only attack that's an issue for both passwords and security key-based sign-in is targeted attacks against a website, where they use your browser to execute malicious API calls to the website after you've signed in regularly.
I'm not familiar with FIDO, but passwords place a lot of effort into the user (must avoid repeating them, must avoid simple sequences, etc). After years of warnings, this has berely changed - people use lousy passwords and repeat them.
So I'm all up for considering different approaches.
No. Google's power to lock people out of their website is already here with the prevalence of 'Sign in with Google'.
FIDO is unrelated; it works by having the browser/device itself sync the virtual security keys[0], much in the same way they sync passwords currently. That's the only thing changing here, giving people the choice (and encouraging them) to sign in via "what you have" instead of "what you know".
I’m sure people way smarter than me have this figured out, from the Google post:
> When you sign into a website or app on your phone, you will simply unlock your phone — your account won’t need a password anymore.
> Instead, your phone will store a FIDO credential called a passkey which is used to unlock your online account. The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone
So if I was a dumb kid, I could login to my parents bank accounts (or more / worst) if my mom gave me her 4 digit phone password for games earlier?
For you perhaps. Phones are shared more often than you think. And no, they don't use multi-account features built into modern mobile operating systems.
Currently on the iPhone, if your FaceID or TouchID fail repeatedly, you have the option to type in the passcode, which grants the same access. I'm not sure if the same is true on Android.
I think the more general point is that "able to unlock the phone" is not / should not be the same as "I have verified that this is you" for sensitive applications and information.
If that kid can get their parent's finger on the fingerprint scanner, sure. The authentication part of the process is moved to the device's security system, so that's fingerprints, passcodes, and facial recognition.
I don’t think fingerprint scanners on consumer devices are always great. My daughter has one on her laptop and last week I tried my finger and it worked.
Honestly, biometrics are terrible for authorization. They're more of a username than a password and we shouldn't use them like passwords. The same is truth for facial recognition algorithms, no matter how advanced.
They're so damn convenient, though. I trust the fingerprint scanner on my phone and my laptop, but there are definitely bad scanners out there.
I've tried unlocking my laptop's scanner with my other hand and I've asked other people to put their finger on it to see if it does some kind of weird matching based on finger type. No problems so far. It even works across both Windows and Linux if I use the right Windows reboot incantations.
Since there is nothing genetic about fingerprints, I'd personally consider your daughter's laptop to be defective if you're able to unlock it. A critical part of the laptop's security mechanisms is clearly broken and should be looked at. I can't find many other stories about Dell specifically so this may be a specific unit or product line that's broken.
You may even have something to gain by reporting it; I don't know if Dell or their manufacturers do bug bounties, but this definitely sounds like something that should be accepted in such a program. Even if they don't, writing a short blog about it with the brand, model, and model of the fingerprint reader might get the press rolling, forcing Dell to take action. This is simply unacceptable.
> Since there is nothing genetic about fingerprints
While it's true that even identical twins don't have the same fingerprints [1], it's not true that there are no genetic factors in the general shape of fingerprints [2]. I agree that it's unacceptable if a fingerprint reader isn't good enough to distinguish identical twins based on the differences in fingerprints though, as those should be the most similar fingerprints possible, essentially setting a floor on the minimum uniqueness in the problem.
It seems like they would use identical twin derived validation data sets to ensure this.
I don't want my password to be something I leave behind on everything I touch, which the police have because I was arrested once, which can be ascertained from high quality photos, and which I can't ever change once stolen.
.. but biometrics can be lost too. I could lose my finger, I could have a facial injury. The algorithm could be changed and suddenly I can't log into anything anymore. Or I simply age and my faceId stops working some day.
I don't know but biometrics only sound smart initially but it seems very brittle if you think about it. Plus there are plenty of stories of people who were able to unlock somebody else's phone randomly. Just google "unlocked my friends phone via faceid".
This all seems like such theater for nothing. I think a simple "own this usb stick = it's proof that you are you" is a very nice 2 factor without any biometrics. Create a usb stick that needs to be unlocked via a passcode to work and voila.
* On Apple devices TouchID allows you to register multiple fingers. And if you have a severe facial injury it will fall back to a password if it can't identity you.
* No one is unlocking their friends phone via FaceID unless they are unconscious and they have deliberately disabled the awake-detection feature.
* It is not theatre for nothing. It is a far more secure and convenient form for authentication.
I think this is really great news and am glad to see FIDO move forward as I think it greatly increases account security.
One aspect of FIDO that could still be troublesome is account recovery in case of inadvertent loss of passkey. OOB recovery with SMS or email is considered too weak and the main recommended alternatives are to maintain multiple authenticators (i.e. multiple copies of your passkeys), re-run onboarding processes for new users or just abandon the account.
It's going to be interesting to see how those alternatives play out in real world situations.
Reading this announcement, the idea seems to be that FIDO keys will be synchronised across devices. That means you can lose your phone and still get access to your accounts from your desktop.
You might even be able to get access by simply logging in to your Microsoft/Apple/Google account on a new device if they implement this system stupidly enough.
Yes, these will be stored in cloud storage like iCloud Keychain. But I can go into my iCloud Keychain and delete individual passkeys - or I may have only one Apple device and then lose it. Or some malware clears out all of my iCloud Keychain.
I haven't look deeply into passkey enough yet, but aren't we replacing "what if I lose by device" by "what if company XYZ decides to nuke my access to my synchronized passkey"?
Suggested edit of mission statement in the name of increased accuracy:
“The standards developed by the FIDO Alliance and World Wide Web Consortium and being led in practice by these innovative companies is the type of forward-leaning thinking that will ultimately make the American people easier to track online.
This will be done by linking all online activity to unique personal attributes, i.e. "their fingerprint or face, or a device PIN." It's basically another step towards the China model of total mass surveillance of the population.
[edit: all the justifications for this proposal - aren't they mostly solved by the use of password managers?]
> You technically should be able to migrate from one provider to another, it remains to be seen how easy Apple and Google will make the process.
On a UX level, the transfer to another syncing security key "provider" is going to be interesting, if they even do that at all - I kind of doubt they'll have a "transfer your iCloud passkeys to your Chrome password manager" and they'll instead say "go to each service and enroll a new security key via your new syncing key manager". On a technical level, I wholly imagine there'll be a tool that pulls iCloud Passkeys[0] via the MacOS Keychain application and then inserts them into your new key manager.
> - so what happens if you don't have your phone at time of login?
Depends on if they allow you to turn off password+2FA login entirely, which I only see being possible with something like Advanced Protection Program[0] which can already be used to enforce "Only allow authentication with my password+security keys; there is no way for Google Support to remove 2fa; if I lose the keys, the account's lost".
> - if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms?
I imagine they'll say "login to each website" (which you can do via iOS if you use qr android login[1]) then "re-enroll with your new provider", but I hope there will be an actual export/import or migration experience.
> - Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
Assuming they don't change how Chrome and iCloud keychain currently works, everything synced should stay on your already signed-in devices, so hopefully you can continue to use your devices as authenticators until you can log into each service and register a regular, hardware key for sign-in.
1: https://www.chromestory.com/2021/12/qr-code-2fa/#:~:text=Her... I personally tried this with my iPhone, and my phone prompted me to use an iCloud Passkey. I was able to confirm that, by enrolling my iPhone as a security key on GitHub, then this 'BLE Webauthn' feature allowed me to sign in to GitHub on my desktop Chrome browser via my phone. Only downside to this is that the desktop must have a bluetooth card, but hopefully motherboards will continue to come integrated with wifi+bluetooth.
>if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms?
A good FIDO implementation will give you the ability to enroll multiple authenticators. In fact, if you can't, you're basically going against the WebAuthn spec.
"Relying Parties SHOULD allow and encourage users to register multiple credentials to the same account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these different credentials are bound to different authenticators."
Basically, you should enroll your iPhone and a backup key. And if you get an Android device, you log in with the Android device using a backup key, and enroll the Android device and remove the iPhone. Alternatively, you remove the iPhone authentication using the iPhone, and enroll the Android device using an alternative authentication method (like traditional username/password).
> - so what happens if you don't have your phone at time of login?
You can’t login. Same as it is with any 2FA system where you don’t have access to the second factor.
> - if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms?
At a minimum services should support multiple authentication devices/tokens. So you can enrol both an iOS device and Android device, or any other FIDO device E.g. YubiKey.
This is already the standard approach for FIDO tokens, and basically a requirement for existing services, because we don’t currently have FIDO token syncing.
I would hope that these syncing services will also allow you to export your private key. But that’s a slightly scary prospect because it would allow the holder of that key to authenticate as you anywhere.
> - Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
Services will still need a credential recovery process. People lose phone etc everyday. I imagine your bank will happy reset your credentials if you turned up in-person holding government identification.
> Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc
If you don't accept their 10,000 word ever-changing terms of use, and if don't let them check for the marks on your forehead or right hand, then yes, you won't be able to buy or sell.
> - Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
You don't need an Apple/Google/Microsoft account to use WebAuthn on another website, it's based on the biometrics on your local device. Syncing that credential across your devices with the same account is just an optional extra feature.
The expectation is that you also have “something you are” as provided by your devices biometric authentication.
The standard allows for service to demand that the authentication device performs an additional factor authentication. Which is usually either a PIN or biometrics, and your device attests to doing this during authentication.
So then you have two complete factors “something you have” (your phone) and “something you are” (biometrics) or “something you know” (unlock PIN for device).
> But I'm responding to GP that said biometrics are a username, not a secret, which I agree.
If you were sending an actual copy of your biometric data to the remote authentication service, then maybe you could make that argument.
But that never happens, no FIDO biometric device sends a biometric fingerprint that could be reproduced by a different device. The device authenticates you with biometrics, then uses that data to unlock a private key, which is then used to answer a challenge-response request from the authenticating service.
If you don’t the device, then it’s pretty much impossible for you to correctly answer that challenge-response, despite being in possession of the biometric features that device would use to authenticate you.
So you can’t use your biometrics as a username. Because the device measuring the biometric data pushes that data through a mono-directional, randomly generated (at device manufacture), hash function, that exists within that device only. Take your biometrics else where (I.e same device type/model but different physical object), and you’ll get a different output even with identical inputs. Which would be a pretty useless username.
> I'm not sure something you are counts as a security factor.
Something you is a an authentication factor that doesn’t need to be secret to be secure. That’s the whole point. You can have a high-res 3d model of my finger but you can’t create a human with my fingerprint.
In the same way that the security of something you know is a scale based on “how difficult is your password to guess” or “how hard is it to crack the hash” the security of something you are is a scale based on “how difficult is it for someone to create a fake that tricks this specific machine into thinking it’s reading metrics from a live human.”
The security lives in the system reading the metrics not your body which is why you don’t have to rotate your face every 90 days.
A cheap fingerprint reader is the 4 digit pin of something you are. Retina scans that take temperature, look for blood flow and eye movement are the correct horse battery staple.
> Bio-metrics are just convenient because they are unique and hard\impossible to replicate.
But if your biometric is able to be faked, you can't change it like you can change a typical text based password. There's no "reset your password" equivalent for biometrics.
I mean you don't have to give it away if you think Google is storing databases of fingerprints for the lizard masters to track you down.
FIDO simply wants to make authentication stronger, you can use hardware keys that have a key burnt into them which is unique and much harder to brute-force than passwords.
Again according to how biometrics are described in whitepapers\industry, we extract features from the fingerprint\face sometimes very little compared to the actual biometric and use it to derive a key.
that key cannot be reversed to get the original features and different algorithms use different features.
> that key cannot be reversed to get the original features
"As a result, the early common belief among the biometrics community of templates irreversibility has been proven wrong. It is now an accepted fact that it is possible to reconstruct from an unprotected template a synthetic sample that matches the bona fide one."
-- Reversing the irreversible: A survey on inverse biometrics
"from an unprotected template" do you even read?
stop trying to find some random internet page to justify yourself, have you ever seen a biometric implementation? I have.
I don't know what counts as a non-random internet page, but here[0] is an article published by the "European Data Protection Supervisor" titled "14 Misunderstandings With Regard To Biometric Identification And Authentication", with number 12 being "Biometric information converted to a hash is not recoverable". It states:
> there are studies showing that the hash could be reversible, that is, it could be possible to obtain the original biometric pattern, especially if the secret of the key used to generate the hash is violated
So yes, there are secret keys involved (which the user has no control over), and no, I've never read through the code of a biometric implementation, but ultimately the space of possible values that someone's face or finger could reliably display is much smaller than even MD5, so it can be brute-forced.
If you have some non-random internet page to justify yourself, and show how much entropy is contained in a biometric hash, and how resistant to cracking that hash is, and how well secured those secret keys are, then I'd be happy to learn more.
Let's ignore the part about biometrics being faked since this seems to be a point of contention.
Isn't it a fair argument that secret keys should be mutable by the user? In the future, some unforeseen event COULD occur which compromises or otherwise renders the particular biometric unusable. Now what?
But they are... Firstly, with how it works. even if you use the same finger to generate hundreds of keys, they should all be different because we are using noise\randomness within the algorithm itself. different sensors will generate different outputs and therefore it is pointless to worry about the key used stolen.
I think what you want is secret keys completely detached from the user. we have that as well with hardware tokens.
Once they have a way to fake your biometric though they have it for forever, that's the point. With a password you have a way to provide a key only known to you and while it can be faked, it can also be reset, you can't reset your fingerprint without surgery
> What's easier to do? stealing someone's fingerprint or cracking\guessing their password.
> Definitely the latter.
You sure about that? A properly generated (i.e. random) password won't be cracked or guessed in any reasonable amount of time, whereas a model of your fingerprint(s) can be lifted from any object you've touched and used to create a silicone mold capable of fooling many fingerprint readers. And you only have 10 of them at best; once all your fingerprints are known to potential attackers that's it; you can't use fingerprint authentication any more for the rest of your life.
Really? can you back this up? I can. I work in the cyber industry for a decade now. I've seen the data, I've seen attempt to bypass both.
Biometrics are by far better for the vast vast majority of people.
Do you even listen to what you're describing here? trailing someone, trying to extract fingerprints? this isn't a Jame Bond movie.
Cyber attacks are common because they are completely digital\anonymous by nature.
Secondly, humans can't remember\generate truly secure passwords, unique for every account they own. they usually rely on a tool like a password manager.
PM are definitely better than weak passwords but are actually weaker than biometrics. they are a central point of failure and have been attacked in the past.
For the average Joe, biometrics are more secure since he is not using such tool anyways.
It doesn't take James Bond to lift some fingerprints off a surface. Anyone with physical proximity and a little practice can manage that much. People have managed to fool fingerprint readers with Gummi Bears before, much less specially-designed equipment. It's a practical attack, unlike attempting to brute-force a truly random 10-character password from a 78-character alphabet (uppercase, lowercase, digits, and half of the 32 symbols on a PC-104 keyboard).
> Secondly, humans can't remember\generate truly secure passwords, unique for every account they own. they usually rely on a tool like a password manager.
Which is perfectly fine. You aren't going to break their password manager either. The weak point is the users who aren't using password managers, because they try to get by with less-than-random passwords which are susceptible to cracking. Or biometrics, which aren't secret at all.
Well it depends on how you define replicate, I'm not aware of a technology that can perfectly recreate someone's face\fingerprint.
a photo\mask isn't perfect and actually in some instances they fail to work vs sensors because of that.
It is more of a question of how robust is the authentication method.(can a photo\mask fool it? which can happen sometime but usually require pretty high quality sample)
I think, at the end of the day, there really isn't much of a difference between the two, for authentication. One is just a public part of who you are, and remains fairly static.
An argument for keeping the username separate is it is often used for identification. That is, you identify on this site as alberth. Not as any biometric scan. Even if you change which finger you want to use to authenticate, you'd still be alberth to everyone else here.
I think there are arguments on favor of letting you change a display name. Probably still would keep a name that is static. (What Twitter does?)
I believe it's because people generally find the idea to be comfortable and familiar based on fictional representations in movies, etc. I'm of the opinion biometric information is totally private, yet easily spoof-able, thus should only be used to identity - not authorize - me.
it's not a dumb question, but that will not stop anyone because biometric authentication works very well in practice (convenient and foolproof) despite beeing not very secure.
i.e. lockpicking howtos and existence of glasscutters don't dissuade from having a locked front door.
Without making any explicit argument for it, what I see coming out of Fido and U2F are really changing the importance of the long-standing "something you have, something you know..." mindset around security. That prior mode was not helping us design system that take human capabilities of the user into account.
Prior security seemed to focus entirely on attackers, and their agency, and what they could potentially do. But we also need to pay attention to what users can do in order to build a secure system. Requiring users to read domain name strings, potentially in Unicode, every time, and make sure they are correct, to prevent phishing, is a really bad design. Instead, have the website authenticate themselves to the user, automatically, and have the machine do the string comparisons.
Similarly, the distinction between user and password for a biometric doesn't make much sense in this case. It's neither. The user is identified by a different mechanism, the biometric is merely a way for the device to see that the user is there.
There are always lots of attack modes for biometrics, but they are convenient and good enough to capture nearly all common and practica attack modes. And a huge problem of the 90s and 2000s security thinking was focusing on the wrong attack modes for the internet age.
> Without making any explicit argument for it, what I see coming out of Fido and U2F are really changing the importance of the long-standing "something you have, something you know..." mindset around security. That prior mode was not helping us design system that take human capabilities of the user into account.
Don’t think that’s quite true. It’s continuation of the old “something you know”, “something you have” and “something you are” authentication factors, and the idea that at least two factors should be used to authenticate.
The username/password approach is only a single factor, “something you know”.
Common 2FA solutions use “something you know” (you’re password) and “something you have” (a device proven via OTP or SMS).
FIDO with biometrics trades all that for 2FA driven by “something you are” (biometrics) and “something you have” (you’re devices Secure Enclave).
You don’t send you biometrics to the service your authenticating with. Rather you’re using your biometrics to prove “something you are” to your device, which your device then mixes with a private key which proves you’re in possession of a known device. All of that is then used to authenticate with your service.
In order to enable a cloud synced private key, you need the syncing process to require 2FA to enable new devices. The 2FA process can be clunky and slow, because you only need to do once per device enrolment. Indeed it’s need to be clunkier, because you don’t have a biometric factor available for use, as the enrolment process is normally used to onboard both a device and a device specific biometric factor.
After that you’re device becomes a know authenticated device, which can be used as “something you have” factor for authentication.
All of this isn’t a change from long standing authentication strategy. It’s just a refinement of process to make the underlying authentication strategy user friendly.
You make very good points! The user focused design work of the FIDO group feels like a large departure of traditional designs, but need not be viewed that way in terms of those elements.
Fundamentally, if you want to support multiple, unlinked accounts per person you'll still need some sort of "account designator."
If you don't then the biometric marker can just replace both password and username. The reason why the username exists for the password is because it's problematic to guarantee uniqueness of passwords across your users. One is unique and public and the other is not and private.
Not it shouldn't. If you wanted to associate various devices (phone, laptop, etc) to the same account it wouldn't work. The fingerprint produced by each device is different.
You associate biometric credentials to a username for that.
The biometrics don't authenticate you to the remote service. They authenticate you to the device that has the keys that authenticate you to the remote service.
Biometrics are a convenient replacement for a screen lock pattern/PIN, but not a necessary one, of course.
The short answer is that you can lose a biometric but still be you. So a biometric is not a username.
Also, the biometric does not actually replace a service password in this instance, it just helps authenticate you locally to a device. The key on the device is what is actually replacing your password.
Depending on the device or settings you choose, you don’t need to use biometrics at all if you don’t want to.
I've resisted switching to a hardware key because I know that I'm going to break it, and that seems like a huge pain in the ass. I really want to be able to make a couple of backup keys, or maybe put another way, I want to be able to put the private key on the device myself, I don't necessarily care that the key is generated on the device and never leaves the device. I don't care if that slightly reduces my security - I'm not protecting nuclear weapons, my threat model is not state actors trying to attack me, my threat model is me leaving my key in my pants pocket before putting it in the washing machine.
It's actually horrible! Even key rotation is horrible!
My yubikey is getting to about 10 years old, and I have replacements for it but find it very difficult to switch. It will eventually fail as an things do and it will be problematic.
The problem is that I have several dozen accounts connected to it and I don't know all of them. So either I'm carrying and trying multiple keys at all times or not getting into a site that haven't been rotated yet.
Multiple keys on an all sites is also basically impossible. You need to register all the keys, and ideally those keys are in different places.
I’m going to need to work this out soon. I picked up a pair of new YubiKey 5Cs yesterday with their sale. I’ve been using a YubiKey Neo for years for U2F, TOTP and GPG.
Moving the GPG key is easy - though I might try using the FIDO2 support in SSH instead. However for every TOTP and U2F key I’m going to have to re-enroll the new keys… It feels like there should be a better way.
It would indeed be nice if you could "cross sign", CA style, a new yubikey with an old one, and that would somehow get passed along to the various services.
I have not thought about the various attack vectors that this may or may not enable though.
I've recently started to track my service dependency graph! So like, to keep using github I need my password store, my email and one of my two security keys. To use my email, I need...
Please contact me if you're interested, I will release the tooling I have.
FIDO2 with resident SSH ed25519 keys works great, just make sure the OpenSSH client and server versions on all the machines you’ll be using the key on support it. I wish there was a way to sign Git commits somehow using them instead of PGP.
I have much more backups of my workstation etc., should I now buy dozens of crypto hardware key thingies and constantly switch them around to match the backup disks?
For those who do offsite backups: Is an offsite backup possible across the Internet? Or do you have to physically drive the key to the offsite location?
When I create a new account somewhere, does that mean I have to move N backup keys out of their drawer to the workstation and register each of them on the account?
And how to even create a backup and keep it in sync?
With backup disks, it is a matter of shutting down the machine, removing one disk from the RAID1, and you have a backup (the removed disk is the backup). Or doing "dd if=..." if you don't use raid.
Is something as simple possible with those fancy crypto toys? Or is some arcane magic required to copy them?
Is this perhaps all as usual: An attempt to get more control and tracking of users, disguised as "security"?
With devices that support BIP39 backups like the Ledger or Trezor, you are backing up the random seed that generates all possible future accounts deterministically.
Backup once, setup 100 accounts, lose authentication device, restore backup to new device, regain access to all 100 accounts. Easy.
I keep an off-site backup at my parents house. Right now it includes a printed copy of my backup codes, so if my house burns down and everything is a total loss here, I at least don't have to start from zero. They live far enough away that my backup offsite backup can get to be a few months out of date but that's usually fine. (If I were to make a major change in something I'd make a special visit)
I don't want to spend a bunch of time when I visit to find that key and add it to all of my new accounts and hope I got everything - I want to make a backup of my current key right before I visit and when I visit, I just put the new backup key in the desk drawer and take the old one home with me.
Right. Some core services get this treatment, like email and important online accounts. For others I rely on reset mechanisms tied to those email accounts if I lose the primary key and haven't had the chance to register the secondary. Every few months I'll sync up anything that has been missed.
It's not perfect, but it's a hell of a lot better than TOTP.
This. For a while I tried to keep a list of accounts I needed to add my offsite key to, and then every year or so I'd retrieve the key, and add in bulk, but that became way too complicated.
While not ideal, I'd be happy if I could register with the public key of my offsite key or something similar. Really I think there should be a way to register a public persona, and add / remove keys from that persona at will.
Or, just let me (somehow) generate multiple hardware devices with a shared seed.
That's exactly why FIDO [1] and WebAuthN [2] are moving towards a concept of backup-able/cross-device-sync-able authenticators.
That is arguably less secure in some contexts, but there are workarounds, and I do see the point that for most services, availability/key loss recovery is as much of a concern as is security.
People have made the same incorrect assumption that fido can't be backed up many times and it is a common misconception that halts adoption of the best security win since TLS. I feel important to correct this in tech circles so we start telling friends and family to setup a solution to the most common account loss problems.
Also, BIP39, the only backup spec that exists for FIDO atm, originated in the Bitcoin community where key loss is a very expensive problem that needed an elegant solution.
BIP39 can be used to backup any type of asymmetric cryptographic key that could ever exist in a human friendly way but sadly I am not aware of any vendors implementing it outside of hardware wallets which are general purpose tools
They can be used for PGP and FIDO and password management without using them for cryptocurrency and this is totally valid.
I absolutely agree that this is a thing that needs to be solved. I cobbled together my own solution using undocumented bits of the Solo firmware[1], but that's not nearly usable enough for average users.
But here's the problem: outside of the hype bubbles, cryptocurrency stuff does not have a good reputation. If the only thing that supports this markets itself as a cryptocurrency wallet, that is going to hurt adoption. People generally do not buy devices in which they actively do not want the main feature.
(I did remind myself of DiceKeys[2] while looking through my notes to find [1], but that has its own problems, such as "oh god what are you doing why does this involve OCRing a photograph of dice on my phone".)
This problem is already well solved and deployed to millions of people. That it is my point.
To your dicekeys example, a much better solution, IMO is using bip39-diceware which allows you to roll for 256 bits of entropy in the form of 24 BIP39 words with dice, using only a paper worksheet. You can use these with a KDF to determinstically generate any type of key material be it for PGP, FIDO2, mutual TLS, or whatever you like.
BIP39 is a general purpose innovation in human friendly cryptography, and so are the general purpose personal HSM devices that support it.
I don't feel it is productive to balk at a generally useful technology just because one dislikes the biggest audience creating demand for it.
Someone can have a religious objection to porn and still enjoy the bandwidth growth and other improvements to the internet that porn demand helped create.
Just because a toaster is marketed for toast, does not mean you can't enjoy it for pop tarts. Just because a pressure cooker has a "chicken" button, dosen't make it any less useful to a vegan.
The examples are endless.
Those that are fundamentally against experiments in decentalizated governance should at least try to appreciate that space presents high stakes security problems that engineers will innovate to solve.
Many of the best cryptographers in the world, like Dan Boneh and team at Stanford, spend a huge amount of their time focusing on innovations in privacy, computational effenciency, and cryptography to meet demand created by popular decentralized systems experiments.
If anything, buy products like hardware wallets that improve security for you and recommend their teams spin up marketing and product development approaches more inclusive of customers that have moral objections to decentralized governance and value storage use cases like yourself.
Okay, so first of all, you know very well that "moral objections to decentralized governance" is not the problem people have with blockchain technology.
But beside that, perhaps I didn't quite make the point of my comment clear enough. You're trying really hard to convince me of things. I know very well how this works, and what problems it solves, and I do think it's a good solution to this problem.
The main reason I'm not going to buy one of these isn't anything about the technology; it's because I already have a solution for myself and I have no reason to bother switching to another solution.
This isn't about my opinions. I'm explaining why the general public is going to continue to ignore this otherwise valid solution. The marketing around it actively ties it to a thing that most people have negative opinions of, and makes the feature they actually want seem like an afterthought. Even here, you repeatedly refer to it as a hardware wallet, because that has always been the primary focus of those devices.
The effect of this is that the average non-blockchain-person just sees you posting a lot of comments in a tangentially related thread trying to sell them on blockchain tech. Do you see why this, from the perspective of a non-blockchain-person, is counterproductive?
You will continue to have trouble getting people to adopt these devices until either the marketing focus changes or public opinion on blockchains changes. And one of those is going to be much easier to accomplish than the other.
I am not telling you this to bash blockchains. I do have negative opinions on that space, but I don't care to debate them here; nothing would be accomplished by either of us by doing so. I am giving you advice on the way your message is perceived by others.
The services I interact with that support WebAuthn usually only allow you to register one key. Backup and recovery is a confusing puzzle for most of these services.
Tell the services you interact with that they're basically going against the spec.
"Relying Parties SHOULD allow and encourage users to register multiple credentials to the same account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these different credentials are bound to different authenticators."
This has been talked about in HN comments almost daily for like a week — does anyone from AWS/Amazon read this forum, or are they too busy performing blood sacrifices trying to recruit graduates?
Most people have smartphones which ship with WebAuthn so they are good to go. Granted phones are like $500+ so by contrast a Yubikey is a much cheaper alternative for a secondary backup device for most people.
I was about to say the same thing. These things are quite sturdy and if you loose your key (as people do) you retire the old one and make a new. These things are neither expensive nor irreplaceable. Of course if you loose your key it's going to hurt, as it should.
I've had a Yubi Key for almost 5 years now. Zero issues.
I wanted to enable YubiKey for my Bitwarden account and feared exactly this. Now I've spent 200€ for 4 YubiKeys, so if I ever miss or break one, I will hopefully be fine. But imagine telling your grandma to buy at least 2 YubiKeys for 100€ just to make your Facebook login more secure.
Has anyone tried a Ledger or Trezor device for something like this? Your FIDO U2F private key is deterministically generated [0] based upon your seed phrase, which you can backup, and restore on other devices.
What do you mean by a honeypot? Both are pretty well trusted devices, and users easily have tens of billions of dollars deposited on them. Given that, I feel pretty comfortable using them for 2fa.
At least Ledger actually does support U2F as an installable application, but that's the predecessor to FIDO and has some weaknesses in comparison. I'm also not sure whether WebAuthN supports legacy U2F authenticators without the browser performing some protocol translation.
I have a Ledger as a backup key. Keyword is backup since it's less convenient to use than a Yubikey due to needing to put in a pincode first. Though that could be a security feature in and of itself.
I have abused and soaked every model of Yubikey. I even melted the casings off every model with acetone to lookup chip specs and Yubico responded by switching to a new unidentified glass hybrid compound no common solvents seem to impact.
In all cases the Yubikeys still worked even as bare abused PCBs. You need a blowtorch or a drill to break one.
Hear hear. I already have enough to worry about besides this little magical security wand failing/getting lost. I require a bullet proof method-of-last-resort mechanism in place for the inevitable day when the fob is no longer available.
I want to have both, a hardware key and a password. A password alone always has to grant me access again, ideally without needing to register a machine too. Honestly I hate that this is so widespread already, I want my devices to be a non-recognizable ghosts for security purposes. An access log would be more appreciated.
I have a Yubikey and use it as a part of my passwords. But I would like to have a second master password that I only use in emergencies. Yes, it is easy to forget so make sure you don't. But a password that is rarely used is also rarely exposed to third parties.
To be honest, the most problems I see with FIDO is the lacking trust in the alliance of companies behind it but I don't know too much about the technicalities of FIDO.
It's reasonably safe to leave them connected to the devices you regularly authenticate from, unless your threat model includes an adversary willing to use physical attacks.
Unless you have some way of authenticating all of your hardware with the key, taking it with you still leaves plenty of options for a physical attacker.
The weakest link in security is always going to be humans. Account compromise is is more often a human problem than a technological one (spamming requests, password reuse, simple passwords, (spear) phishing, direct social engineering, etc).
If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords. Easier to use. Easier to social engineer a compromise.
I get regular requests to get into my Microsoft account using their new login form that sends a key code rather than prompting for password. "Passwordless" just means that prompt goes to an app where a user unlocks their device to approve the login.
This seems like worse security, not better. I'm okay with an approval prompt if it's part of a multi-factor auth system. Not if it's the only auth.
But isn't the "thing" about FIDO (or maybe just security keys?) that the domain is also integrated into the challenge the client/key has to solve?
So from what I understand a attacker couldn't as easily fish me by pretending e.g. to be Google.
With a password or even a TOTP code the attacker could just pose as Google and forward the credentials to the actual site.
You're looking at an exploit from a technological point of view, which I expect this community is likely to do. Think of it from the perspective of the average user. I know for a fact if my mom was told by an attacker "if you see an approval request for your account, just accept it" she would do so. It's taken time to train her not to give anyone her password.
I've read of attackers with valid passwords spamming logins in hopes to trick a user into approving the auth. Whether it's because it woke up the user and they're in a sleep fog, or they're busy and not paying attention.
Microsoft, at some point, changed their login flow so that, by default, when you enter your username, it sends a pin. I receive regular attempts at this. This isn't going to work out for the attacker because they have to get the pin. But if all that's required is a button press, the attacker could just make the login request and wait.
With multi-factor auth, where a password is in use, you have to get past the password before getting to that auth approval. It reduces how much noise the user gets and the chances of success for the attacker.
You don't understand FIDO/webauthn/etc. The scenario you describe is impossible. This is the genius - the user is totally cut out of the equation, there is no action your mom can take on phishing-website.com to send the credentials of google.com, because the key will refuse to do so.
What this article is about is authenticating the request with an app on your phone, not a hardware key. This ends up being a device totally disconnected from the device requesting the auth, and neither have to be in the same geographic location unless implemented alongside the spec.
The article specifically discusses auth via app, but if it's involving the FIDO alliance, it'd be weird to exclude hardware keys, I guess. I still don't like the idea of going single factor, but if it's with a hardware key, I can see it being better than with an app since it has to directly interact with the process itself.
But, of course, if this is optional, I still have to reference the end users. I'm willing to pay for an authentic FIDO key, which can be a tad costly. Your typical user might be more inclined to go for a cheap one that does enough to get into the account, and may not be trustworthy, or would prefer not to do it at all.
My understanding is that the theoretical app being discussed behaves in the same way as a hardware key - it is simply a software-only implementation of the protocol (and thus comes with the same advantages).
> If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords.
It isn't only easier, it's significantly more secure. FIDO/U2F is basically immune to phishing, because there's no one-time code to type and steal; there's a cryptographically backed signing assertion guaranteeing the person with physical possession of the token is in control. This is so airtight (because almost all account compromise is done remotely, not through physical in-person attacks) that I would even be personally comfortable disclosing my password for accounts secured by FIDO/U2F.
In a multi-factor scheme, I would agree with you. I use FIDO/U2F myself...as a secondary factor.
There are active attacks that attempt to exploit human lack of vigilance in an authentication approval flow. With a password as a first factor, it reduces the chances that these attempts make it to the user.
You and I are probably fine in terms of vigilance. If I see an auth request, say, from my Okta app, that I did not initiate, I know it's something I need to investigate and will not automatically approve it. But consider the typical user...
>"Passwordless" just means that prompt goes to an app where a user unlocks their device to approve the login.
Setup a yubikey with an attested cert/pub key. Require a pin to use said yubikey.Requiring attestation will prove that private key was generated on the device, and will only live on that yubikey. That's your best bet.
It also satisfies the multi-factor needs. The something you have is the yuibkey. The something you know is the PIN.
There's a frequent misconception that hardware keys are no better than, say, a TOTP seed on a secure element of your phone.
The core practical difference between a hardware key and that TOTP code on a secure element is the hardware key, when registered with a domain, is programmed with the domain name in it. Lookalike domains - or anything besides the exact domain you registered the key with - fail to 2FA because they are unregistered. This essentially prevents (spear)phishing attacks from stealing login credentials.
Absolutely right - put another way: the responsibility of the user is reduced from "be absolutely certain that you're entering your credentials to the web site that you think you're authenticating at" to "provide consent to authenticate".
That's pretty much what happened here. Obviously it's going to look a bit different afterwards because you have to mathematically tangle the time, key, and domain together. You can't really do that with the six digits of a traditional OTP code.
And like the other reply stated, if you can't mathematically tie them together, you have to rely on the user validating the domain (which you can't).
If a user manually enters a code from TOTP device/calculator into a website, that TOTP device/calculator has no way to know which exact website domain it is - if the user visiting notmybank.com thinks they are visiting mybank.com, they'll get the right code for mybank.com from their device and get pwned.
The key part of FIDO protocol is that it prevents the user from getting the code intended from one domain and sending it to a different domain.
But this seems like a technological solution to a very human problem. If I can trick a user into approving the login, then hardware fobs, secure elements, etc, are meaningless.
The audience here is likely to assume that the security is solid. And it probably is. But this is a technology targeting your average user. It'll certainly be easier for the end user. But it seems like it introduces a human-based attack vector that may be easier to exploit.
What I mean is: with modern hardware keys you literally can't trick a user into approving a remote login, or a login to a fake domain. It's not possible unless you can control the domain that the user is logging into (say you've got code execution on their machine or compromised their network and broken TLS, attacks which are significantly more complex than phishing). Hardware keys enforce that the device can only authenticate against the real domain, not a phishing domain. The core of this is a real improvement of how 2FA works at the protocol layer, rather than simply a change to how the user interacts with the device.
Hardware keys also require that the key can only authenticate a local session, so there's also no risk that your "hardware key tap" can be captured and used by a remote adversary who doesn't control the local computer.
That's why with webauthn humans are not part of the auth scheme anymore. All the auth is negotiated between machines(web browser -> domain name -> hardware key storage).
I don't trust Google or Apple to be my main authentication provider, or to manage syncing my private key. Their customer service is terrible and they are way too arbitrary on locking folks out.
I would trust my bank (well, my credit union.) I can go see them in person if I need to and they take my lawyer seriously, they also take security seriously, they're properly regulated, and ultimately they're my main concern if someone stole my credentials, so I'd like them to be on the hook for protecting my credentials.
This announcement isn't about that and neither provider is asking to sync your private key. In fact the opposite is true: with FIDO2, you're in much greater control of your account security because authentication creds are now on a hardware token versus as bearer credentials you type and an adversary can steal and replay. Many of us believe we're very good at protecting our passwords, but this isn't true in reality and FIDO2/U2F standards objectively make accounts more secure precisely because they remove humans from the equation.
Except it kind of is - the way I read this is "Apple/Google will turn your phone into a hardware FIDO token, but will use iCloud/whatever to reduce the huge painpoint of having more than one hardware token and keeping them all in sync"
I really love the idea of FIDO and making sure that my authenticator only authenticates to sites that I've approved, but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future.
Your average user is more concerned about losing their password than they are about authenticator sovereignty. Moving towards cryptographic primitives for auth versus shared secrets is a net benefit versus current state.
> but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future.
Compromise is necessary, and probably a bit of regulation from government to enforce good outcomes from exception handling. Passkeys need to be stored and managed somehow, and your average user does not want to do that, just like they don't want to run their own mail server, syncthing instance, or mastodon instance.
EDIT: (HN throttling, can't reply) @signal11 You can already be locked out of all of those accounts without recourse.
> Your average user is more concerned about losing their password than they are about authenticator sovereignty
Right up to the point when they’re locked out from their Google, iCloud or Facebook accounts with little recourse or appeal. And then they discover it’s not just Google, a whole host of other services don’t work.
And it does happen, and I for one don’t want to wait for legislation to mitigate this blatant attempt at yet more centralisation.
Many authenticator apps allow you to extract and back up the private key yourself, with no involvement of any 3rd party. But it's a totally optional workflow and you're never asked for that private key while authenticating, so the mass phishing and spear-phishing attacks seen with passwords are still infeasible.
This is a net benefit over synced passwords, which everyone already trusts them to do. You haven't been forced to use a (syncing) password manager over a physical password book in the past, and you won't be forced to use Passkeys[0] or the Android equivalent in the future; hardware security keys will still be usable since this announcement is about embracing the FIDO Standard.
> neither provider is asking to sync your private key.
Yes, they are. According to the white paper linked in the press release:
Just like password managers do with passwords, the underlying OS platform will “sync” the cryptographic keys that belong to a FIDO credential from device to device.
Not at all, because before anybody could take your account away from you if you did not accurately compare two visual strings, potentially in Unicode.
By replacing that operation, which humans can not perform reliably, with computer operations, users are no longer subject to others taking control of their account.
This announcement is partially about the platform-integrated authenticators being made into 'virtual' authenticators backed by a platform vendor-specific cloud ecosystem. So for example, a credential registered on an iPhone may be synchronized over iCloud Keychain to work to log in my Mac via TouchID.
This is something which has always been as part of the model - an authenticator is just an abstract thing that represents an authentication factor, generates keys for a particular use, and doesn't share private keys outside its boundaries.
This announcement possibly marks a transition where sites supporting Web Authentication (with a bring-your-own-authenticator model) will go from seeing 90%+ hardware-bound authenticators to seeing 90%+ platform-integrated, synchronizing authenticators. Bundled into that prediction is a hope that this (and other proposed changes) will lead to a 10x increase in adoption.
In the Netherlands the banks provide the iDIN system, so you can authenticate on more sites with the bank provided logins. Each bank has a slightly different system often using bank card and bank card readers and ways to authenticate through authorised banking app on individual mobile phones.
And besides that we have also a government provided login system which can also even work with your ID card. But mostly works with government systems and health insurance companies.
Tracking from bank or both? Anyways, in Latvia we have similar system and it is a convenient way to authenticate within services where you MUST prove you are person X.Y.Z.
For example, some electric company, if you auth via this method, will provide you with contracts, electricity usage graphics for all the sites you own and and other info you must access as a customer. Same goes for recycling company. These usually provide a way to register using email matching whatever email you had in contract (thus linking to real person anyway)
And then for other services where you request some data electronically that they must "register" each request. For example request some extended data on land/house ownership. You can't have that with non-real-life identifiable entity.
So usually login via bank is an login option with companies you either have juridical relationships or you must provide real life identity where you would otherwise have to show passport in real life.
We have GDPR and consumer focused regulators in the EU. Our governments are actually out to protect citizens from corporate malfeasances, as opposed to either ignoring it, or out right enabling it.
If a company abuses this data, you have strong forms of recourse available to you as a citizen, and banks are incentivised to remove bad actors, to ensure they don't become embroiled in enforcement action triggered by a 3rd party.
There is no comparison between Google and Apple customer support, and they should not be mentioned in the same sentence. Google support is nonexistent. With Apple, I can chat online or get in person support. They are more like a bank.
Despite what most people think, banks are often a really long way behind on security. Banks don't care about security of any individual customer, merely security of the bank as a whole. That means if 0.01% of customers lose all their funds due to credential stuffing, it isn't an issue - the bank will just refund them if needed.
Unlike say ssh with key authentication, where it would be a total failure if 0.01% of attackers were allowed to login without the key.
Let me add my recent experience in the bucket. Few days ago I upgraded my legacy Workspace account to a business account. (I was in a time crunch; couldn't evaluate alternatives.) I enter my debit card details in the checkout and got a generic error message asking me to "try again later." Thought there was something wrong with their service and tried the next day. Same error. After some 15 minutes of searching forums, turns out debit card is not supported in my country on account of SMS based TOTP, which doesn't work for subscription services. (If they could mention it in the haystack of their help pages, why can't they say that right when I signup?)
Anyway, more searching led to an alternative. There's an option to request invoiced billing where I would get a monthly bill & pay - debit card works here. Clicking that option took me to form. Filled it, got a call from a sales guy few hours later. Sadly, he had no clue about my problem, despite being from my country. On top of that he told me he's from a different team and don't deal with sales queries (WTF. Then why did he call me?). Told me he'd email me some options and, at that point I wasn't hopeful. Thought he would send me some stuff I had already seen on their forums. On seeing the said email, my disappointment sank even lower. The generic mail had absolutely nothing to do with my issue and the help urls were totally unrelated.
I just ended up using my friend's credit card to complete the transaction. I'm seriously considering moving elsewhere.
Is product management this pathetic at Google? I'm sure if you went for a PM interview they'd judge you nine ways to Sunday. For what? Everything Google does seems like it's built by three robots in a trench coat collaborating unsuccessfully with other robots in trench coats.
I recently moved my family's legacy GSuite service over to Fastmail, and it seems like they've carefully planned for this exact scenario. Account setup on each device is as simple as downloading a configuration profile with a QR code. And Fastmail has a built-in option to authenticate to your old Google account and pull all your mail over to the new account, preserving all the details, and then keep sync'ing until you're ready to turn the old account off. I thought I was going to have to sync things myself. Nope! Took all of five minutes to set up my account and sync. Couple weeks later I deactivated the old GSuite accounts.
And now I'm a customer again, which feels good, even though it means spending actual money.
The FIDO Standard talked about here includes regular security keys, so, if you don't want to use passkey, you can get a physical security key; and while I imagine the push for passwordless will be large, I doubt they'll completely remove passwords anytime soon.
no thanks. I don't want one account that apple/google/whoever can revoke and ruin my online life. fuck that. I'll take my chances with 2FA and passwords. When it finally gets breached (if you haven't been cancelled!) imagine how much one online cracker will able to do. This also allows them unlimited access to follow you all around and see what you do, where you log in, etc.
524 comments
[ 2.8 ms ] story [ 303 ms ] threadIt all depends on the sync method provided. If synchronisation isn't end-to-end protected, you're handing Apple/Google/Microsoft the keys to the kingdom which is pretty bad.
Maybe the parent misread the spec as saying a _maximum_ of 100,000? Or something?
Also, the Alliance could decide to blacklist a manufacturer just because they haven't implemented some new policy (like requiring a DNA scan of the user) so you better make sure that you buy a device from one of the "too big to fail" providers.
1. By what mechanism can they blacklist a device? A given relying party can choose to use or not use attestation and, if they choose to use it, which certificates to trust. But that's between you and the RP. Authentication doesn't "talk to" the FIDO Alliance--which is just a standards body and does not (AFAIK) even publish anything like a CRL for "bad" attestation keys, so I don't understand what you are talking about here.
2. The intention of the attestation, as I understand it, is to enable RPs to use attestation to limit authenticators to e.g. those that pass FIPS certification (or similar enterprisey requirements), not to ban a whole batch because one key is known to be compromised. That's crazy; can you point out where anyone other than you has ever proposed this?
3. DNA scan? What are you talking about?
4. This assertion you are making, while bizarre and wrong, is very different than the assertion the grandparent made ("Yubikeys intentionally have a very small number of devices signed with one CA key...so those devices do have a basically unique identifier"), which, while also wrong, is I think a genuine mistake and not a bad-faith argument.
True, and a website could decide to issue its own certificates rather than get one from a CA trusted by browsers, but in practice (and potentially one day by law) most sites will defer to the FIDO Alliance to determine which devices are "sufficiently secure".
> the FIDO Alliance--which is just a standards body and does not (AFAIK) even publish anything like a CRL for "bad" attestation keys
"The FIDO Alliance Metadata Service (MDS) is a centralized repository of the Metadata Statement that is used by the relying parties to validate authenticator attestation and prove the genuineness of the device model."[0]
> That's crazy; can you point out where anyone other than you has ever proposed this?
"If the private ECDAA attestation key sk of an authenticator has been leaked, it can be revoked by adding its value to a RogueList."[1]
> DNA scan? What are you talking about?
I picked a deliberately extreme example to make the point that there are requirements for these devices that users might not be happy with (but might not have any choice about, once the capability becomes ubiquitous). That specific example may never come to pass, but I don't think we should assume that allowing RPs to put arbitrary conditions on the hardware we use is a power that won't be abused.
For added context: "FIDO will soon be launching a biometric certification program that ensures biometrics correctly verify users. Both certifications show up as metadata about the authenticator, providing more information to enable services to establish stronger trust in the authenticators.)"[2]
> This assertion you are making, while bizarre and wrong ... a bad-faith argument.
Maybe you should have assumed good faith.
[0] https://fidoalliance.org/metadata/
[1] https://fidoalliance.org/specs/fido-uaf-v1.2-rd-20171128/fid...
[2] https://fidoalliance.org/fido-technotes-the-truth-about-atte...
That’s quite different. In your example, if a website does so unilaterally, client user agents break. In the FIDO case, nobody else knows or cares which authenticators an RP trusts.
More broadly, I don’t get this conspiracy theory. You’re worried…the FIDO alliance will abuse their very limited power to…what end?
> If the private ECDAA attestation key sk of an authenticator has been leaked, it can be revoked by adding its value to a RogueList."[1]
The attestation key, which is shared among all devices? That’s rather different from what you said.
> That specific example may never come to pass, but I don't think we should assume that allowing RPs to put arbitrary conditions on the hardware we use is a power that won't be abused.
RPs already have such power. Today they use it to do things like require password complexity policies. Again, RPs aren’t the FIDO alliance; they’re the actual website you’re logging into.
Your repeated argument here is that websites should not be allowed to impose restrictions on how their users authenticate, which is hard to fathom.
In a previous version of this argument, I remember you essentially arguing that banks and enterprises should not be able to restrict what types of authenticators their employees and customers use.
I get it. You hate attestation. But “my employees must use a fips-certified key” (or “my customers must use a hardware key”) is reasonable and ultimately non-negotiable if you want people to use your protocol.
I think this is the crux of where our disagreement lies. I grudgingly accept that FIDO makes it easier for companies to check that their employees are storing their keys on company-approved devices, but I don't think that arbitrary websites should be given the power to make demands about the hardware that visitors must use to create accounts. That seems like a worse position for user freedom than we have today with passwords.
You might say that websites already have this power, in some convoluted way. They could say "Enter your credit card details and postal address here and we'll send you a custom device you can use to log in to our website", but in practice no company does that. (Banks and governments are maybe special cases, and less concerning given that: their authenticators are managed out of band; they are highly regulated; they usually have actual branches that you can go to in person to sort things out; and people generally choose to interact with banks/governments that are based in their own country).
Attestation changes the market dynamics here. Suddenly it becomes acceptable for sites to bully users into buying certain types of devices, and for governments to start demanding that these devices be used as online IDs (at least for age verification, to start with). Even if companies don't abuse this power to keep people in their ecosystem (e.g. Apple sites giving you special features if you log in with an Apple device), the first casualties are going to be open source hardware and software implementations, which will be deemed insecure, and further normalise the idea that users can't go online without running proprietary code.
I agree the potential exists, in a hypothetical sense. But the dynamics are very different than you describe (with your analogy to the CA ecosystem, which, ironically, gives big platform owners far more power—yet has no evidence of such abuse!).
Right now, there is just not that much use of WebAuthn and FIDO. You’re the guy saying, “if we find a way to lower global temperatures, we should fear an ice age.” It’s premature to say the least.
The important difference with the CA ecosystem is that (in the worst case) the big platform owners can put pressure on small websites to obtain a certificate from one of a large number of competing issuers. Significantly, these issuers are not the same as the big OS providers themselves, and there are issuers who issue certificates for free. That is completely the reverse of 3 big platforms forcing end users to buy hardware, and those platforms being hardware vendors themselves.
> You’re the guy saying, “if we find a way to lower global temperatures, we should fear an ice age.”
No, I'm the frog saying "Hey, isn't this water getting a bit warm? Don't you think we should jump out before it's too late?"
- is transparent
- is mediated by the FIDO Alliance; the platform makers cannot do it unilaterally, as they can with CAs in browsers
- is mediated by the RPs; even if the FIDO Alliance did do this for some reason, RPs could just ignore it with no ill effects, unlike with CA trust in browsers
- wouldn't have any effect today for the vast majority of RPs, since the vast majority do not even use attestation today
- honestly, isn't something they have any incentive to do; hardware security keys are not a meaningful source of revenue for someone like Apple, Microsoft, or Google
I'm guessing you've never worked in a big tech company before if you think they have an incentive to do that. :)
Also, why not allow uncertified devices to generate keys? Why do I have to implement secure boot or TPM?
But as long as the ridiculous SMS 2FA is removed or replaced by something better, then fine. But we'll see how this goes.
From the web side of this standard, this also tells me that Mozilla has no influence anywhere and will be the last ones to implement this standard in Firefox.
Oh dear.
You choose to use Google, and can attest to the fact it's not that difficult not to.
This standard is unrelated; it works by having the browser/device itself sync the virtual security keys[0], much in the same way they sync passwords currently. That's the only thing changing here, giving people the choice (and encouraging them) to sign in via "what you have" instead of "what you know", but along with that they want to alleviate the UX concerns of people not being ready to carry around a separate physical security key.
0: https://developer.apple.com/documentation/authenticationserv...
Coming soon to an EU country near you!
The EU digital markets act address this issue directly, by requiring “gatekeepers” to provide human customer response, and clear processes for appealing bans etc and generally forcing companies to provide something akin to due-process.
Funnily enough, a system for signing web authentication requests from a mobile device is far from new: I've been using https://krypt.co/ for years (though it's on the long road of sunsetting right now) and I hope that will last long enough for the new cross device standard to replace it.
It's possible that the TPM spec will be updated to allow for loading pre-encrypted data into the TPM store as a response to this. Alternatively, existing secure computing systems (SGX/TrustZone) can also be used to decrypt the synchronised key relatively securely.
instead they wrap/seal everything instead with a layer of crypto, then you can pass that wrapped object around as much as you want, only the TPM can unseal it
a TPM could easily be instructed to seal an internally generated secret with additional escrow keys for MS/Apple/...
that plus remote attestation could make it so you can never see the key in the clear
The problem is that you need private/public key pairs that are synchronised across devices for FIDO to work properly cross-device. When you register an account on your phone, you need that account key on your desktop to use it there, and that's nearly impossible without some kind of key sharing mechanism.
I'm not sure I'm down with any of that.
If push comes to shove, I'm sure someone will develop a lightweight Android emulation layer you can run in the cloud that pretends to be a phone enough that you can use it.
The root of trust for which extends to who knows where, and you're not allowed to look at the source code or learn how it works because that would threaten Hollywood's profit margins.
We're basically building a system of DRM for access to human beings, and making the whole world dependent on these unaccountable entities.
Technologies like Intel's management engine and SGX or their AMD/Qualcom/Apple counterparts are definitely problematic for user freedom in the way they're implemented. However, the TPM system itself is quite neutral: usually, you can clear it from the UEFI, lock it with a password (though that might need to be done from the OS) leaving whatever hostile OS you may run unable to exert any control on the device whatsoever.
I'm personally a big fan of technologies like TPMs and secure boot as long as they're user configurable. I want to be able to install my own keys and force the system to only boot operating systems of my choice. Secure boot with just the MS keys is quite silly and ever since that one version of Grub could be exploited it's basically useless; secure boot with user or enterprise keys can be an incredible tool for defence in depth, for example when visiting countries where border agents may try to gain access to your data without your permission or knowledge (China, USA, etc.).
If I had my way, I'd use Coreboot together with Secure Boot, with encryption keys stored in a TPM, the transfer of which goes through an encrypted channel (a feature of TPM 2.0 that nobody uses) after unlocking it with a password. Sadly, most Linux OS developers have a grudge against these technologies because they're used by companies such as Microsoft and Apple to reduce user freedom on some of their devices.
this isn't true: there's a hash blacklist which is (supposed) to be regularly updated by your OS update mechanism
windows update does it anyway
official list is here: https://uefi.org/revocationlistfile
(I have my own root configured for all of my machines so only stuff I've signed can boot)
If it weren't for that small detail then I would agree that TPMs can be useful for secure key storage and the like, working for the device's owner and not against them. The actually useful (to the owner) parts of the TPM do not require the manufacturer's signature.
program generates random bytes->ask tpm to sign it->on signature return, program asks TPM for its public key->program verifies public key matches that of the signature->verify the public key is cross-signed by the manufacturer's certificate authority. The only attack here would be if Intel or AMD's PKI is compromised, which would certainly be leveraged against enterprise customers before any consumer customers got hit.
The issue could be addressed without removing the ability to attest as to the TPM's origin by including a protocol for the owner to dump the device's private encryption keys (e.g. by shorting one of the external pins to ground). The fixed attestation key set by the manufacturer would need to be restricted so that it can only be used to sign attestation messages, with all other keys being generated on the device so that they can be reset when the device changes owners.
Mass surveillance. You can just say mass surveillance.
> moving the trust boundary away from the control of the user entirely. I also don't enjoy it, but it would solve a lot of current problems we see in information security.
Every despot throughout history has noted that freedom can be traded for security, but I thought that most of us would agree that freedom is more important.
It's very hard to make a privacy case against FIDO. Practically speaking it's one of the best things that happened to privacy&security since the invention of asymmetric cryptography. The deployment of this tech reduces phishing effectiveness to near zero, or in many cases literally zero.
With username and password, I have full control over my privacy in a very easy to understand fashion: If I randomly generate them I know I cannot be tracked (as long as I ensure my browser doesn't allow it by other means).
With those keys I have a opaque piece of hardware which transfers an opaque set of data to each website I use and I have NO idea what data that is because I do not manually type it in. I need to trust the hardware.
Sure, I could read the standard, but it very likely is complex enough that it is impossible to understand and trust for someone who has no crypto background.
And I also have no guarantee that the hardware obeys the standard. It might violate it in a way which makes tracking possible. Which is rather likely, because why else would big tech companies push this if it didn't benefit them in some way?
They switched to this internally a long time ago which basically eliminated phishing attacks against employees. There are security teams inside those megacorps that have a general objective of reducing the number of account takeovers, and non trivial resources to accomplish that. Not everything is a conspiracy.
Also, I am sure you will be able to stick to just passwords for a pretty long time while the world moves on to cryptographic authentication. I'm not being sarcastic here.
Said security teams have at most zero incentive that the privacy of the policy subjects is preserved.
The same corporations that routinely intercept all network traffic.
With your password manager, you're trusting a lot more: the software of the OS and kernel, the software of the browser and its dependencies, the software of your password generator and your password storage. You also have to hope the developers and administrators of the website you're signing in to aren't storing your passwords in plain text (and I don't just mean in the database - overly-aggressive APM/logging might be storing POST request data in a log stream somewhere).
The only attack that's an issue for both passwords and security key-based sign-in is targeted attacks against a website, where they use your browser to execute malicious API calls to the website after you've signed in regularly.
So I'm all up for considering different approaches.
FIDO is unrelated; it works by having the browser/device itself sync the virtual security keys[0], much in the same way they sync passwords currently. That's the only thing changing here, giving people the choice (and encouraging them) to sign in via "what you have" instead of "what you know".
> When you sign into a website or app on your phone, you will simply unlock your phone — your account won’t need a password anymore.
> Instead, your phone will store a FIDO credential called a passkey which is used to unlock your online account. The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone
So if I was a dumb kid, I could login to my parents bank accounts (or more / worst) if my mom gave me her 4 digit phone password for games earlier?
I think the more general point is that "able to unlock the phone" is not / should not be the same as "I have verified that this is you" for sensitive applications and information.
Of course, if you've enrolled your kid's fingerprints they'd have access.
> you will simply unlock your phone
Then I guess that really is no different from opening an app.
They're so damn convenient, though. I trust the fingerprint scanner on my phone and my laptop, but there are definitely bad scanners out there.
FWIW, my daughter's laptop is a Dell.
Since there is nothing genetic about fingerprints, I'd personally consider your daughter's laptop to be defective if you're able to unlock it. A critical part of the laptop's security mechanisms is clearly broken and should be looked at. I can't find many other stories about Dell specifically so this may be a specific unit or product line that's broken.
You may even have something to gain by reporting it; I don't know if Dell or their manufacturers do bug bounties, but this definitely sounds like something that should be accepted in such a program. Even if they don't, writing a short blog about it with the brand, model, and model of the fingerprint reader might get the press rolling, forcing Dell to take action. This is simply unacceptable.
While it's true that even identical twins don't have the same fingerprints [1], it's not true that there are no genetic factors in the general shape of fingerprints [2]. I agree that it's unacceptable if a fingerprint reader isn't good enough to distinguish identical twins based on the differences in fingerprints though, as those should be the most similar fingerprints possible, essentially setting a floor on the minimum uniqueness in the problem.
It seems like they would use identical twin derived validation data sets to ensure this.
1. https://www.nytimes.com/2004/11/02/health/the-claim-identica...
2. https://www.mcgill.ca/oss/article/did-you-know/you-inherit-p...
* No one is unlocking their friends phone via FaceID unless they are unconscious and they have deliberately disabled the awake-detection feature.
* It is not theatre for nothing. It is a far more secure and convenient form for authentication.
Anyone got a link to something less hand-wavey and more concrete?
One aspect of FIDO that could still be troublesome is account recovery in case of inadvertent loss of passkey. OOB recovery with SMS or email is considered too weak and the main recommended alternatives are to maintain multiple authenticators (i.e. multiple copies of your passkeys), re-run onboarding processes for new users or just abandon the account.
It's going to be interesting to see how those alternatives play out in real world situations.
You might even be able to get access by simply logging in to your Microsoft/Apple/Google account on a new device if they implement this system stupidly enough.
I think the idea is that passkeys are synced between devices, see e.g.:
https://developer.apple.com/videos/play/wwdc2021/10106/
I haven't look deeply into passkey enough yet, but aren't we replacing "what if I lose by device" by "what if company XYZ decides to nuke my access to my synchronized passkey"?
“The standards developed by the FIDO Alliance and World Wide Web Consortium and being led in practice by these innovative companies is the type of forward-leaning thinking that will ultimately make the American people easier to track online.
This will be done by linking all online activity to unique personal attributes, i.e. "their fingerprint or face, or a device PIN." It's basically another step towards the China model of total mass surveillance of the population.
[edit: all the justifications for this proposal - aren't they mostly solved by the use of password managers?]
It sounds like it's still a one factor authentication system, but different.
- so what happens if you don't have your phone at time of login?
- if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms?
- Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
You technically should be able to migrate from one provider to another, it remains to be seen how easy Apple and Google will make the process.
That last one is a great question that I don't know the answer to.
On a UX level, the transfer to another syncing security key "provider" is going to be interesting, if they even do that at all - I kind of doubt they'll have a "transfer your iCloud passkeys to your Chrome password manager" and they'll instead say "go to each service and enroll a new security key via your new syncing key manager". On a technical level, I wholly imagine there'll be a tool that pulls iCloud Passkeys[0] via the MacOS Keychain application and then inserts them into your new key manager.
0: https://developer.apple.com/documentation/authenticationserv...
Depends on if they allow you to turn off password+2FA login entirely, which I only see being possible with something like Advanced Protection Program[0] which can already be used to enforce "Only allow authentication with my password+security keys; there is no way for Google Support to remove 2fa; if I lose the keys, the account's lost".
> - if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms?
I imagine they'll say "login to each website" (which you can do via iOS if you use qr android login[1]) then "re-enroll with your new provider", but I hope there will be an actual export/import or migration experience.
> - Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
Assuming they don't change how Chrome and iCloud keychain currently works, everything synced should stay on your already signed-in devices, so hopefully you can continue to use your devices as authenticators until you can log into each service and register a regular, hardware key for sign-in.
0: https://landing.google.com/advancedprotection/
1: https://www.chromestory.com/2021/12/qr-code-2fa/#:~:text=Her... I personally tried this with my iPhone, and my phone prompted me to use an iCloud Passkey. I was able to confirm that, by enrolling my iPhone as a security key on GitHub, then this 'BLE Webauthn' feature allowed me to sign in to GitHub on my desktop Chrome browser via my phone. Only downside to this is that the desktop must have a bluetooth card, but hopefully motherboards will continue to come integrated with wifi+bluetooth.
A good FIDO implementation will give you the ability to enroll multiple authenticators. In fact, if you can't, you're basically going against the WebAuthn spec.
"Relying Parties SHOULD allow and encourage users to register multiple credentials to the same account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these different credentials are bound to different authenticators."
Basically, you should enroll your iPhone and a backup key. And if you get an Android device, you log in with the Android device using a backup key, and enroll the Android device and remove the iPhone. Alternatively, you remove the iPhone authentication using the iPhone, and enroll the Android device using an alternative authentication method (like traditional username/password).
You can’t login. Same as it is with any 2FA system where you don’t have access to the second factor.
> - if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms?
At a minimum services should support multiple authentication devices/tokens. So you can enrol both an iOS device and Android device, or any other FIDO device E.g. YubiKey.
This is already the standard approach for FIDO tokens, and basically a requirement for existing services, because we don’t currently have FIDO token syncing.
I would hope that these syncing services will also allow you to export your private key. But that’s a slightly scary prospect because it would allow the holder of that key to authenticate as you anywhere.
> - Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
Services will still need a credential recovery process. People lose phone etc everyday. I imagine your bank will happy reset your credentials if you turned up in-person holding government identification.
If you don't accept their 10,000 word ever-changing terms of use, and if don't let them check for the marks on your forehead or right hand, then yes, you won't be able to buy or sell.
You don't need an Apple/Google/Microsoft account to use WebAuthn on another website, it's based on the biometrics on your local device. Syncing that credential across your devices with the same account is just an optional extra feature.
Its not like InfoSec cares if the business functions, that's not their job.
The standard allows for service to demand that the authentication device performs an additional factor authentication. Which is usually either a PIN or biometrics, and your device attests to doing this during authentication.
So then you have two complete factors “something you have” (your phone) and “something you are” (biometrics) or “something you know” (unlock PIN for device).
If you were sending an actual copy of your biometric data to the remote authentication service, then maybe you could make that argument.
But that never happens, no FIDO biometric device sends a biometric fingerprint that could be reproduced by a different device. The device authenticates you with biometrics, then uses that data to unlock a private key, which is then used to answer a challenge-response request from the authenticating service.
If you don’t the device, then it’s pretty much impossible for you to correctly answer that challenge-response, despite being in possession of the biometric features that device would use to authenticate you.
So you can’t use your biometrics as a username. Because the device measuring the biometric data pushes that data through a mono-directional, randomly generated (at device manufacture), hash function, that exists within that device only. Take your biometrics else where (I.e same device type/model but different physical object), and you’ll get a different output even with identical inputs. Which would be a pretty useless username.
> I'm not sure something you are counts as a security factor.
You should take that up with NIST then: https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/m...
In the same way that the security of something you know is a scale based on “how difficult is your password to guess” or “how hard is it to crack the hash” the security of something you are is a scale based on “how difficult is it for someone to create a fake that tricks this specific machine into thinking it’s reading metrics from a live human.”
The security lives in the system reading the metrics not your body which is why you don’t have to rotate your face every 90 days.
A cheap fingerprint reader is the 4 digit pin of something you are. Retina scans that take temperature, look for blood flow and eye movement are the correct horse battery staple.
Username is simply an ID. Password is how we truly verify who the user is.
Bio-metrics are just convenient because they are unique and hard\impossible to replicate.
But if your biometric is able to be faked, you can't change it like you can change a typical text based password. There's no "reset your password" equivalent for biometrics.
The signal from the sensor is used as a "seed" to generate key using robust cryptography
Different sensors will output different "data" based on the sensor type.
right, who would do that... i mean for what purpose...
FIDO simply wants to make authentication stronger, you can use hardware keys that have a key burnt into them which is unique and much harder to brute-force than passwords.
Again according to how biometrics are described in whitepapers\industry, we extract features from the fingerprint\face sometimes very little compared to the actual biometric and use it to derive a key. that key cannot be reversed to get the original features and different algorithms use different features.
"As a result, the early common belief among the biometrics community of templates irreversibility has been proven wrong. It is now an accepted fact that it is possible to reconstruct from an unprotected template a synthetic sample that matches the bona fide one."
-- Reversing the irreversible: A survey on inverse biometrics
https://www.sciencedirect.com/science/article/pii/S016740481...
> there are studies showing that the hash could be reversible, that is, it could be possible to obtain the original biometric pattern, especially if the secret of the key used to generate the hash is violated
So yes, there are secret keys involved (which the user has no control over), and no, I've never read through the code of a biometric implementation, but ultimately the space of possible values that someone's face or finger could reliably display is much smaller than even MD5, so it can be brute-forced.
If you have some non-random internet page to justify yourself, and show how much entropy is contained in a biometric hash, and how resistant to cracking that hash is, and how well secured those secret keys are, then I'd be happy to learn more.
[0] https://edps.europa.eu/sites/edp/files/publication/joint_pap...
also you
> We leave biometric traces everywhere, all the time. do you cover your face and wear gloves in public? hmmmm...
Unless you have a drivers license in California where they require inked versions of your biometrics.
Isn't it a fair argument that secret keys should be mutable by the user? In the future, some unforeseen event COULD occur which compromises or otherwise renders the particular biometric unusable. Now what?
I think what you want is secret keys completely detached from the user. we have that as well with hardware tokens.
As I explained you can't get the fingerprint from the device\key, it is simply not there.
This isn't the problem of the implementation\technology if someone stole your fingerprint. it didn't lead to your biometrics compromised
What's easier to do? stealing someone's fingerprint or cracking\guessing their password.
Definitely the latter.
> Definitely the latter.
You sure about that? A properly generated (i.e. random) password won't be cracked or guessed in any reasonable amount of time, whereas a model of your fingerprint(s) can be lifted from any object you've touched and used to create a silicone mold capable of fooling many fingerprint readers. And you only have 10 of them at best; once all your fingerprints are known to potential attackers that's it; you can't use fingerprint authentication any more for the rest of your life.
Do you even listen to what you're describing here? trailing someone, trying to extract fingerprints? this isn't a Jame Bond movie.
Cyber attacks are common because they are completely digital\anonymous by nature.
Secondly, humans can't remember\generate truly secure passwords, unique for every account they own. they usually rely on a tool like a password manager.
PM are definitely better than weak passwords but are actually weaker than biometrics. they are a central point of failure and have been attacked in the past.
For the average Joe, biometrics are more secure since he is not using such tool anyways.
It doesn't take James Bond to lift some fingerprints off a surface. Anyone with physical proximity and a little practice can manage that much. People have managed to fool fingerprint readers with Gummi Bears before, much less specially-designed equipment. It's a practical attack, unlike attempting to brute-force a truly random 10-character password from a 78-character alphabet (uppercase, lowercase, digits, and half of the 32 symbols on a PC-104 keyboard).
> Secondly, humans can't remember\generate truly secure passwords, unique for every account they own. they usually rely on a tool like a password manager.
Which is perfectly fine. You aren't going to break their password manager either. The weak point is the users who aren't using password managers, because they try to get by with less-than-random passwords which are susceptible to cracking. Or biometrics, which aren't secret at all.
Password based biometrics is the last place I would look at for biometric compromise.
We leave biometric traces everywhere, all the time. do you cover your face and wear gloves in public? hmmmm...
a photo\mask isn't perfect and actually in some instances they fail to work vs sensors because of that.
It is more of a question of how robust is the authentication method.(can a photo\mask fool it? which can happen sometime but usually require pretty high quality sample)
An argument for keeping the username separate is it is often used for identification. That is, you identify on this site as alberth. Not as any biometric scan. Even if you change which finger you want to use to authenticate, you'd still be alberth to everyone else here.
I think there are arguments on favor of letting you change a display name. Probably still would keep a name that is static. (What Twitter does?)
i.e. lockpicking howtos and existence of glasscutters don't dissuade from having a locked front door.
Prior security seemed to focus entirely on attackers, and their agency, and what they could potentially do. But we also need to pay attention to what users can do in order to build a secure system. Requiring users to read domain name strings, potentially in Unicode, every time, and make sure they are correct, to prevent phishing, is a really bad design. Instead, have the website authenticate themselves to the user, automatically, and have the machine do the string comparisons.
Similarly, the distinction between user and password for a biometric doesn't make much sense in this case. It's neither. The user is identified by a different mechanism, the biometric is merely a way for the device to see that the user is there.
There are always lots of attack modes for biometrics, but they are convenient and good enough to capture nearly all common and practica attack modes. And a huge problem of the 90s and 2000s security thinking was focusing on the wrong attack modes for the internet age.
Don’t think that’s quite true. It’s continuation of the old “something you know”, “something you have” and “something you are” authentication factors, and the idea that at least two factors should be used to authenticate.
The username/password approach is only a single factor, “something you know”.
Common 2FA solutions use “something you know” (you’re password) and “something you have” (a device proven via OTP or SMS).
FIDO with biometrics trades all that for 2FA driven by “something you are” (biometrics) and “something you have” (you’re devices Secure Enclave).
You don’t send you biometrics to the service your authenticating with. Rather you’re using your biometrics to prove “something you are” to your device, which your device then mixes with a private key which proves you’re in possession of a known device. All of that is then used to authenticate with your service.
In order to enable a cloud synced private key, you need the syncing process to require 2FA to enable new devices. The 2FA process can be clunky and slow, because you only need to do once per device enrolment. Indeed it’s need to be clunkier, because you don’t have a biometric factor available for use, as the enrolment process is normally used to onboard both a device and a device specific biometric factor.
After that you’re device becomes a know authenticated device, which can be used as “something you have” factor for authentication.
All of this isn’t a change from long standing authentication strategy. It’s just a refinement of process to make the underlying authentication strategy user friendly.
Pardon my pedantry, but you should only use the apostrophe (') to show you are joining two words.
In this case, the words are "you" and "are", merging into "you're". "you are password" is what I read.
> "but you should only use the apostrophe (') to show you are joining two words. In this case, the words are "you" and "are", merging into "you're"."
Is obvious, unnecessary and condescending.
If you don't then the biometric marker can just replace both password and username. The reason why the username exists for the password is because it's problematic to guarantee uniqueness of passwords across your users. One is unique and public and the other is not and private.
You associate biometric credentials to a username for that.
Biometrics are a convenient replacement for a screen lock pattern/PIN, but not a necessary one, of course.
https://www.wired.com/story/fido-alliance-ios-android-passwo... is a good explainer.
Also, the biometric does not actually replace a service password in this instance, it just helps authenticate you locally to a device. The key on the device is what is actually replacing your password.
Depending on the device or settings you choose, you don’t need to use biometrics at all if you don’t want to.
My yubikey is getting to about 10 years old, and I have replacements for it but find it very difficult to switch. It will eventually fail as an things do and it will be problematic.
The problem is that I have several dozen accounts connected to it and I don't know all of them. So either I'm carrying and trying multiple keys at all times or not getting into a site that haven't been rotated yet.
Multiple keys on an all sites is also basically impossible. You need to register all the keys, and ideally those keys are in different places.
Moving the GPG key is easy - though I might try using the FIDO2 support in SSH instead. However for every TOTP and U2F key I’m going to have to re-enroll the new keys… It feels like there should be a better way.
I have not thought about the various attack vectors that this may or may not enable though.
Please contact me if you're interested, I will release the tooling I have.
[0] https://github.blog/2021-11-15-highlights-from-git-2-34/#tid... [1] https://git-scm.com/docs/git-config#Documentation/git-config...
I have much more backups of my workstation etc., should I now buy dozens of crypto hardware key thingies and constantly switch them around to match the backup disks?
For those who do offsite backups: Is an offsite backup possible across the Internet? Or do you have to physically drive the key to the offsite location?
When I create a new account somewhere, does that mean I have to move N backup keys out of their drawer to the workstation and register each of them on the account?
And how to even create a backup and keep it in sync?
With backup disks, it is a matter of shutting down the machine, removing one disk from the RAID1, and you have a backup (the removed disk is the backup). Or doing "dd if=..." if you don't use raid.
Is something as simple possible with those fancy crypto toys? Or is some arcane magic required to copy them?
Is this perhaps all as usual: An attempt to get more control and tracking of users, disguised as "security"?
Backup once, setup 100 accounts, lose authentication device, restore backup to new device, regain access to all 100 accounts. Easy.
I don't want to spend a bunch of time when I visit to find that key and add it to all of my new accounts and hope I got everything - I want to make a backup of my current key right before I visit and when I visit, I just put the new backup key in the desk drawer and take the old one home with me.
It's not perfect, but it's a hell of a lot better than TOTP.
While not ideal, I'd be happy if I could register with the public key of my offsite key or something similar. Really I think there should be a way to register a public persona, and add / remove keys from that persona at will.
Or, just let me (somehow) generate multiple hardware devices with a shared seed.
That is arguably less secure in some contexts, but there are workarounds, and I do see the point that for most services, availability/key loss recovery is as much of a concern as is security.
[1] https://fidoalliance.org/multi-device-fido-credentials/
[2] https://github.com/w3c/webauthn/issues/1714
Now your one time backup covers all current and future services.
Are there things that support this that aren't cryptocurrency wallets?
Also, BIP39, the only backup spec that exists for FIDO atm, originated in the Bitcoin community where key loss is a very expensive problem that needed an elegant solution.
BIP39 can be used to backup any type of asymmetric cryptographic key that could ever exist in a human friendly way but sadly I am not aware of any vendors implementing it outside of hardware wallets which are general purpose tools
They can be used for PGP and FIDO and password management without using them for cryptocurrency and this is totally valid.
But here's the problem: outside of the hype bubbles, cryptocurrency stuff does not have a good reputation. If the only thing that supports this markets itself as a cryptocurrency wallet, that is going to hurt adoption. People generally do not buy devices in which they actively do not want the main feature.
(I did remind myself of DiceKeys[2] while looking through my notes to find [1], but that has its own problems, such as "oh god what are you doing why does this involve OCRing a photograph of dice on my phone".)
[1] https://github.com/solokeys/solo1/blob/4.1.5/fido2/ctaphid.c...
[2] https://dicekeys.com/
To your dicekeys example, a much better solution, IMO is using bip39-diceware which allows you to roll for 256 bits of entropy in the form of 24 BIP39 words with dice, using only a paper worksheet. You can use these with a KDF to determinstically generate any type of key material be it for PGP, FIDO2, mutual TLS, or whatever you like.
BIP39 is a general purpose innovation in human friendly cryptography, and so are the general purpose personal HSM devices that support it.
I don't feel it is productive to balk at a generally useful technology just because one dislikes the biggest audience creating demand for it.
Someone can have a religious objection to porn and still enjoy the bandwidth growth and other improvements to the internet that porn demand helped create.
Just because a toaster is marketed for toast, does not mean you can't enjoy it for pop tarts. Just because a pressure cooker has a "chicken" button, dosen't make it any less useful to a vegan.
The examples are endless.
Those that are fundamentally against experiments in decentalizated governance should at least try to appreciate that space presents high stakes security problems that engineers will innovate to solve.
Many of the best cryptographers in the world, like Dan Boneh and team at Stanford, spend a huge amount of their time focusing on innovations in privacy, computational effenciency, and cryptography to meet demand created by popular decentralized systems experiments.
If anything, buy products like hardware wallets that improve security for you and recommend their teams spin up marketing and product development approaches more inclusive of customers that have moral objections to decentralized governance and value storage use cases like yourself.
But beside that, perhaps I didn't quite make the point of my comment clear enough. You're trying really hard to convince me of things. I know very well how this works, and what problems it solves, and I do think it's a good solution to this problem.
The main reason I'm not going to buy one of these isn't anything about the technology; it's because I already have a solution for myself and I have no reason to bother switching to another solution.
This isn't about my opinions. I'm explaining why the general public is going to continue to ignore this otherwise valid solution. The marketing around it actively ties it to a thing that most people have negative opinions of, and makes the feature they actually want seem like an afterthought. Even here, you repeatedly refer to it as a hardware wallet, because that has always been the primary focus of those devices.
The effect of this is that the average non-blockchain-person just sees you posting a lot of comments in a tangentially related thread trying to sell them on blockchain tech. Do you see why this, from the perspective of a non-blockchain-person, is counterproductive?
You will continue to have trouble getting people to adopt these devices until either the marketing focus changes or public opinion on blockchains changes. And one of those is going to be much easier to accomplish than the other.
I am not telling you this to bash blockchains. I do have negative opinions on that space, but I don't care to debate them here; nothing would be accomplished by either of us by doing so. I am giving you advice on the way your message is perceived by others.
"Relying Parties SHOULD allow and encourage users to register multiple credentials to the same account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these different credentials are bound to different authenticators."
One of the implications here being that you have zero available authenticators if your main authenticator breaks.
https://www.w3.org/TR/webauthn-2/
they do know about it (I had a friend who was a PM there), but it's low priority...
All of the accounts require username / passowrd and the Yubikey. I'm not willing to not have a password.
"YubiKey Survives Ten Weeks in a Washing Machine"
I think you'll be safe! :)
https://www.yubico.com/press-releases/yubikey-survives-ten-w...
These were the larger ones. Not sure how the smaller "nano" ones would perform.
I've had a Yubi Key for almost 5 years now. Zero issues.
[0] https://www.reddit.com/r/ledgerwallet/comments/udzx1c/ledger...
In all cases the Yubikeys still worked even as bare abused PCBs. You need a blowtorch or a drill to break one.
I have a Yubikey and use it as a part of my passwords. But I would like to have a second master password that I only use in emergencies. Yes, it is easy to forget so make sure you don't. But a password that is rarely used is also rarely exposed to third parties.
To be honest, the most problems I see with FIDO is the lacking trust in the alliance of companies behind it but I don't know too much about the technicalities of FIDO.
Though, general acceptance of QR Codes does seem to have finally taken off.
If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords. Easier to use. Easier to social engineer a compromise.
I get regular requests to get into my Microsoft account using their new login form that sends a key code rather than prompting for password. "Passwordless" just means that prompt goes to an app where a user unlocks their device to approve the login.
This seems like worse security, not better. I'm okay with an approval prompt if it's part of a multi-factor auth system. Not if it's the only auth.
So from what I understand a attacker couldn't as easily fish me by pretending e.g. to be Google. With a password or even a TOTP code the attacker could just pose as Google and forward the credentials to the actual site.
I've read of attackers with valid passwords spamming logins in hopes to trick a user into approving the auth. Whether it's because it woke up the user and they're in a sleep fog, or they're busy and not paying attention.
Microsoft, at some point, changed their login flow so that, by default, when you enter your username, it sends a pin. I receive regular attempts at this. This isn't going to work out for the attacker because they have to get the pin. But if all that's required is a button press, the attacker could just make the login request and wait.
With multi-factor auth, where a password is in use, you have to get past the password before getting to that auth approval. It reduces how much noise the user gets and the chances of success for the attacker.
For me the question is if this is a webauthn thing in general or a security key thing (to include the domain in the challenge to prevent phishing)
But, of course, if this is optional, I still have to reference the end users. I'm willing to pay for an authentic FIDO key, which can be a tad costly. Your typical user might be more inclined to go for a cheap one that does enough to get into the account, and may not be trustworthy, or would prefer not to do it at all.
It isn't only easier, it's significantly more secure. FIDO/U2F is basically immune to phishing, because there's no one-time code to type and steal; there's a cryptographically backed signing assertion guaranteeing the person with physical possession of the token is in control. This is so airtight (because almost all account compromise is done remotely, not through physical in-person attacks) that I would even be personally comfortable disclosing my password for accounts secured by FIDO/U2F.
There are active attacks that attempt to exploit human lack of vigilance in an authentication approval flow. With a password as a first factor, it reduces the chances that these attempts make it to the user.
You and I are probably fine in terms of vigilance. If I see an auth request, say, from my Okta app, that I did not initiate, I know it's something I need to investigate and will not automatically approve it. But consider the typical user...
Setup a yubikey with an attested cert/pub key. Require a pin to use said yubikey.Requiring attestation will prove that private key was generated on the device, and will only live on that yubikey. That's your best bet.
It also satisfies the multi-factor needs. The something you have is the yuibkey. The something you know is the PIN.
The core practical difference between a hardware key and that TOTP code on a secure element is the hardware key, when registered with a domain, is programmed with the domain name in it. Lookalike domains - or anything besides the exact domain you registered the key with - fail to 2FA because they are unregistered. This essentially prevents (spear)phishing attacks from stealing login credentials.
* Most users have no idea what a domain name is.
* It is tedious to compare the domain name character by character.
* Phishing sites have used many UI tricks historically to make their domain name look authentic (e.g lookalike Unicode characters).
And like the other reply stated, if you can't mathematically tie them together, you have to rely on the user validating the domain (which you can't).
The key part of FIDO protocol is that it prevents the user from getting the code intended from one domain and sending it to a different domain.
The audience here is likely to assume that the security is solid. And it probably is. But this is a technology targeting your average user. It'll certainly be easier for the end user. But it seems like it introduces a human-based attack vector that may be easier to exploit.
Hardware keys also require that the key can only authenticate a local session, so there's also no risk that your "hardware key tap" can be captured and used by a remote adversary who doesn't control the local computer.
This is not true whatsoever.
Humans will always be a weakness for sure. But hardly the “weakest”, and hardly “always”
I would trust my bank (well, my credit union.) I can go see them in person if I need to and they take my lawyer seriously, they also take security seriously, they're properly regulated, and ultimately they're my main concern if someone stole my credentials, so I'd like them to be on the hook for protecting my credentials.
I really love the idea of FIDO and making sure that my authenticator only authenticates to sites that I've approved, but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future.
> but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future.
Compromise is necessary, and probably a bit of regulation from government to enforce good outcomes from exception handling. Passkeys need to be stored and managed somehow, and your average user does not want to do that, just like they don't want to run their own mail server, syncthing instance, or mastodon instance.
EDIT: (HN throttling, can't reply) @signal11 You can already be locked out of all of those accounts without recourse.
Right up to the point when they’re locked out from their Google, iCloud or Facebook accounts with little recourse or appeal. And then they discover it’s not just Google, a whole host of other services don’t work.
And it does happen, and I for one don’t want to wait for legislation to mitigate this blatant attempt at yet more centralisation.
Better to not centralise in the first place.
0: https://developer.apple.com/documentation/authenticationserv...
Yes, they are. According to the white paper linked in the press release:
Just like password managers do with passwords, the underlying OS platform will “sync” the cryptographic keys that belong to a FIDO credential from device to device.
https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho...
Ars Technica had a better write-up of these announcements back in March: https://arstechnica.com/information-technology/2022/03/a-big...
By replacing that operation, which humans can not perform reliably, with computer operations, users are no longer subject to others taking control of their account.
It is wonderful.
This is something which has always been as part of the model - an authenticator is just an abstract thing that represents an authentication factor, generates keys for a particular use, and doesn't share private keys outside its boundaries.
This announcement possibly marks a transition where sites supporting Web Authentication (with a bring-your-own-authenticator model) will go from seeing 90%+ hardware-bound authenticators to seeing 90%+ platform-integrated, synchronizing authenticators. Bundled into that prediction is a hope that this (and other proposed changes) will lead to a 10x increase in adoption.
- https://www.idin.nl/en/about-idin/
- https://nl.wikipedia.org/wiki/IDIN - (Use translate function in browser to read as there is no English version
And besides that we have also a government provided login system which can also even work with your ID card. But mostly works with government systems and health insurance companies.
- https://en.wikipedia.org/wiki/DigiD
- https://www.digid.nl/en
I'd frankly prefer "insecure" user+pass over all of these guardrails which are 90% about control over the users and 10% about security.
For example, some electric company, if you auth via this method, will provide you with contracts, electricity usage graphics for all the sites you own and and other info you must access as a customer. Same goes for recycling company. These usually provide a way to register using email matching whatever email you had in contract (thus linking to real person anyway)
And then for other services where you request some data electronically that they must "register" each request. For example request some extended data on land/house ownership. You can't have that with non-real-life identifiable entity.
So usually login via bank is an login option with companies you either have juridical relationships or you must provide real life identity where you would otherwise have to show passport in real life.
If a company abuses this data, you have strong forms of recourse available to you as a citizen, and banks are incentivised to remove bad actors, to ensure they don't become embroiled in enforcement action triggered by a 3rd party.
Despite what most people think, banks are often a really long way behind on security. Banks don't care about security of any individual customer, merely security of the bank as a whole. That means if 0.01% of customers lose all their funds due to credential stuffing, it isn't an issue - the bank will just refund them if needed.
Unlike say ssh with key authentication, where it would be a total failure if 0.01% of attackers were allowed to login without the key.
Let me add my recent experience in the bucket. Few days ago I upgraded my legacy Workspace account to a business account. (I was in a time crunch; couldn't evaluate alternatives.) I enter my debit card details in the checkout and got a generic error message asking me to "try again later." Thought there was something wrong with their service and tried the next day. Same error. After some 15 minutes of searching forums, turns out debit card is not supported in my country on account of SMS based TOTP, which doesn't work for subscription services. (If they could mention it in the haystack of their help pages, why can't they say that right when I signup?)
Anyway, more searching led to an alternative. There's an option to request invoiced billing where I would get a monthly bill & pay - debit card works here. Clicking that option took me to form. Filled it, got a call from a sales guy few hours later. Sadly, he had no clue about my problem, despite being from my country. On top of that he told me he's from a different team and don't deal with sales queries (WTF. Then why did he call me?). Told me he'd email me some options and, at that point I wasn't hopeful. Thought he would send me some stuff I had already seen on their forums. On seeing the said email, my disappointment sank even lower. The generic mail had absolutely nothing to do with my issue and the help urls were totally unrelated.
I just ended up using my friend's credit card to complete the transaction. I'm seriously considering moving elsewhere.
Is product management this pathetic at Google? I'm sure if you went for a PM interview they'd judge you nine ways to Sunday. For what? Everything Google does seems like it's built by three robots in a trench coat collaborating unsuccessfully with other robots in trench coats.
I recently moved my family's legacy GSuite service over to Fastmail, and it seems like they've carefully planned for this exact scenario. Account setup on each device is as simple as downloading a configuration profile with a QR code. And Fastmail has a built-in option to authenticate to your old Google account and pull all your mail over to the new account, preserving all the details, and then keep sync'ing until you're ready to turn the old account off. I thought I was going to have to sync things myself. Nope! Took all of five minutes to set up my account and sync. Couple weeks later I deactivated the old GSuite accounts.
And now I'm a customer again, which feels good, even though it means spending actual money.
Assume every password for every user on your site has been leaked. What now?
This dramatically reduces the potential exposure to phishing and password leaks.
What happens when there is an outage at Google or Apple?
What happens when I lose/get stolen/break/change my cell phone?
What happens if I do not have/want a cell phone?
WebAuthn works with hardware tokens, so something like a Yubikey will also work.
What are you even going on about?
As long as you have access to your FIDO authenticator, you'll still be able to use it regardless of what they do with your account.