441–450 of 525 posts
Earlier quoted context omitted.
For one, it's only ever seen once: during initialization.
In addition, I believe it is not stored on the device. So it can't be exhilarated.
Seriously, though, paper is better for most people that managing device cloning or the like. Most people can have a notebook in their house as a backup-of-last resort. Asking folks to become HSM managers seems unlikely to lead to better outcomes.
Earlier quoted context omitted.
Cryptographically speaking it's signing a challenge, not encrypting a value (which would be a public key operation), but generally speaking yes, that's the idea of it! One of the things FIDO adds beyond a protocol for "plain" hardware-generated and stored keys is the idea of attestation, i.e. authenticators being able to express statements like "keys can never leave this authenticator" or "this key requires PIN or fi…
However, you should not require attestation for public services. If you let Jim sign up with his dog's name as a password, but then refuse to let Sarah sign in because her FIDO device wouldn't provide "attestation" you're crazy. Attestation probably isn't the correct choice for almost anybody, but the cases where it could at least make sense are if you're an employer checking employee authenticators, if you gave ever…
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
Depending on how it's implemented it could still use the same mechanism, couldn't it? (genuine question) 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)
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 p…
Earlier quoted context omitted.
A backup key could have ability to reject original one, problem solved...
How would that work in practice? Key/certificate revocation is notoriously hard.
Are 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.
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…
Earlier quoted context omitted.
For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token? (I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key) EDIT: My ideal setup,…
I do NOT want to use my phone. It cannot be considered to be a secure device given the 'network' baseband control chipset will never be owned by the phone's buyer and has full access to the device.
That's not to say that you should trust modern smartphones. That's up to you. It's just that in whatever "trust" means to you, the baseband urban legend shouldn't come into the equation.
Earlier quoted context omitted.
Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.
A backup key is a good idea, but there needs to be a way to enroll the backup key for a new account (ideally automatically) without the key being physically present, since otherwise you can't (practically) store the backup key off-site. To this end, you should be able to enroll a key using only the public part of the keypair.
This is huge! It sounds like they're finally going implement cross-device synced credentials; a move I've been advocating now for the last two and a half years[1]. Widespread support for this feature is, in my opinion, the last thing needed to make WebAuthn viable as a complete replacement for passwords on the web. The white paper is here: https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... Seems like the…
I went through the white paper, yet still don’t completely understand how it is supposed to work cross device, granted I’m new to Fido. Let’s say I have the same key synched between my laptop, smartphone and tablet. When I wake up in the morning, will there be a ceremony of unlocking my phone (standard non Fido way I guess?) then unlock my tablet from my phone, then the laptop from one of unlocked devices ? With some…
But this 'passwordless' trend is more about signing into websites - If they do implement singing into other devices, I don't think many people will do it (but it's possible - Windows Hello already allows you to sign in with a security key and disable signing in with the MSA password).
0: https://developer.apple.com/documentation/authenticationserv...