Earlier quoted context omitted.
Are there any existing implementations I should be aware of?
https://github.com/danstiner/rust-u2f https://github.com/google/OpenSK
OpenSK is mainly intended for flashing onto a device like a nordic dongle.
Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
261–270 of 525 posts
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#262Earlier quoted context omitted.
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 logi…
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.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#263Earlier quoted context omitted.
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.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#264Earlier quoted context omitted.
Ideally there would be a way to create "tickets" or something from an authenticator in advance and then use them for registration without physical access to the device. Then I could have 100 tickets from my backup on my master, keep the physical backup in a secure offsite location, and enroll new services using master + backup-tickets. When I run out of tickets, generate 100 more. Being able to export/back up/restore…
This sounds suspiciously like PGP subkeys. Having not read into how FIDO works, I'm going to now assume it works by supplying a "public key" to a third party, and the third party authenticates by having you encrypt a nonce with a private key. How far off am I?
FIDO involves creating a new public/private key pair for each website, to prevent cross website tracking. The keys are derived from a secret stored on the device, so the device doesn't need to store anything but that secret, which enables it to be used with a limitless number of websites.
Edit: there seems to have been a paper that studied the very question of "can you create keys asynchronously so that you can later use them with a backup key": https://eprint.iacr.org/2020/1004.pdf https://www.youtube.com/watch?v=urJ2DhpLAEk
I need to read the paper however on how feasible an implementation of this is, and how much buy-in it needs from website and browser vendors.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#265Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.
Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.
Yep! Just store your backup key in a safe-deposit box with your bank.
Then go get it every time you sign up for a new account so you can make it the backup for that account
then go store it again.
and again. and again. and again.
oh no! you lost your key! time to go to the bank to get your backup, sign in to all the accounts, remove the old key, register a new backup, oh wait, got to wait for the new backup to ship, so i guess you can't do that yet. hope you don't lose your key in the meantime, anywho, time to spend a few hours painstakingly removing your lost key from all the 9 thousand sites you use.
yay! its a week to a month later, you finally got your new yubikey shipped, time to go log into to 9 thousand websites again to set it up as the backup for all of the sites.
Ok, time to take it down to the bank.
whats this? a cool new app my friend wants to show me, ok, time to go drive to the bank and get my backup key out of storage and sign up for this cool new app.
You know, this whole driving to the bank thing, its kinda inconvenient, maybe i should just store it in my closet safe.
What do you mean the gas line under my house exploded? but both my yubikeys are in there!
----
The above is fiction, and even under fiction it seems ridiculous how this would really go is even worse:
"Go get my backup key to use for this new app my friend showed me? fuck that"
. .
"What do you mean i can't reset my password, but i lost my yubikey!"
"No, i didn't want to get up to grab my backup token when i was registering."
"Oh wait! i bet i still have the recovery codes as a pdf in my downloads folder. its a good thing no viruses ever think to look in there"
----
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#266Earlier quoted context omitted.
I think they're referring to attestation ( https://fidoalliance.org/fido-technotes-the-truth-about-atte... .), which requires that attestation certificates be shared with a minimum of 100,000 other devices in order to ensure they're not unique IDs. Maybe the parent misread the spec as saying a _maximum_ of 100,000? Or something?
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…
> 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.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#267Earlier quoted context omitted.
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.
Why do you trust your laptop scanner? Have you let other people try to unlock with their fingerprint? FWIW, my daughter's laptop is a Dell.
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.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#268The problem with any key based auth or biometric auth is a user can be compelled by LEO to hand over private keys or open a biometric lock. Passwords are protected by the 5th amendment.
> Passcodes can therefore be compelled if their existence, possession and authentication are "foregone conclusions," the court said in the August 2020 ruling, determining the 5th Amendment's foregone conclusion exception applied in the case.
https://www.reuters.com/business/legal/us-supreme-court-nixe...
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#269The problem with any key based auth or biometric auth is a user can be compelled by LEO to hand over private keys or open a biometric lock. Passwords are protected by the 5th amendment.
I think the main problem I’m never buying into Fido keys anymore is that mine point blank stopped working and I had to sweat to get back in website that supported it, hopefully back then not many, but if identity is the responsibility of a close piece of hardware if it breaks you’re out
Normally you can assign multiple keys to one identity. That's baked into WebAuthn and pretty much all the implementations I've seen do it.
Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard
#270The problem with any key based auth or biometric auth is a user can be compelled by LEO to hand over private keys or open a biometric lock. Passwords are protected by the 5th amendment.
Why do we need another AuthN protocol? We should extend OIDC as needed instead of again trying to reinvent the wheel.
Because the interaction with the hardware authenticator is local.
OIDC and WebAuthn can work together.