←back to thread

225 points Terretta | 1 comments | | HN request time: 0.001s | source
Show context
itohihiyt ◴[] No.41856240[source]
I only need one provider. A portable open source encrypted database I'm in control of and can back up and secure as needed. It's what I have now, and have had for years, in my password manager. I won't be at the mercy of a company or a device to access my digital life.
replies(3): >>41856321 #>>41856331 #>>41862108 #
leokennis ◴[] No.41856321[source]
That's cool, but the last thing I would want my mom to have to manage is a portable open source encrypted database shes's in control of and can back up and secure as needed.
replies(3): >>41856328 #>>41857755 #>>41863274 #
saurik ◴[] No.41856328[source]
Great; but, as long as a system supports the open solution, anyone can provide for you the closed one, while the opposite isn't the case.
replies(1): >>41856410 #
izacus ◴[] No.41856410[source]
And Passkeys is an open solution, what are you all going on about?
replies(2): >>41856536 #>>41856572 #
politelemon ◴[] No.41856536[source]
Currently it is not. It was created provider centric so far, and in my reading of the spec, a thinly veiled lockin. The ability to move around should have been built in from the beginning but it was more beneficial for the providers to start without.
replies(2): >>41856627 #>>41857724 #
growse ◴[] No.41857724[source]
Passkeys are just resident webauthn tokens with a fancy name.

Where's the lockin?

replies(1): >>41857869 #
reginald78 ◴[] No.41857869[source]
The attestation anti-feature which is part of the spec. And the portability feature which is conspicuously not. The former makes the enforcement of the later possible.
replies(1): >>41859013 #
growse ◴[] No.41859013[source]
The attestation is part of the webauthn spec, and it's up to the relying party to decide whether or not to use it. The whole reason it's there is to give some contexts the ability to narrow their users down to specific webauthn storage implementations (which is useful in some corporate / gov contexts).

Are there any examples of any widely-used sites that are enforcing attestation?

replies(1): >>41860063 #
whs ◴[] No.41860063[source]
Two comes to mind:

- Cloudflare had a "captcha" POC called "Cryptographic Attestation of Personhood" where you need to use a FIDO-approved token. It's reusing U2F just for the attestation part only. I don't think it ever go to production as most people don't have a token (but perhaps in the future hardware-locked passkey may serve as one...)

- Okta do have an option to enforce attestation. By default it is off, but in my Okta production I can limit the list to FIDO-approved vendor only, or to even a subset of them. They also have a beta feature flag for blocking Passkeys but allowing physical keys (which they do not guarantee success)

replies(1): >>41862124 #
warkdarrior ◴[] No.41862124[source]
OK, so you gave two examples of systems that do NOT enforce attestation (one that is not in production, one that has an option to enforce attestation but is not apparently in use).

Are there any widely-used sites that actually enforce attestation?

replies(3): >>41863405 #>>41863455 #>>41865361 #
9dev ◴[] No.41863455[source]
It’s absurd, really. Attestation is clearly a feature intended for high security environments, where you want to ensure all employees use their corporate hardware authenticators and those only, yet people act like it’s big techs secret, evil mind control back door.
replies(3): >>41863684 #>>41863756 #>>41863784 #
ndriscoll ◴[] No.41863756[source]
If it's only meant to be used for those environments, then attestation data should not be provided by default. IT can enable it on managed devices.
replies(1): >>41864466 #
growse ◴[] No.41864466[source]
It's up to the provider as to whether they provide or not. I don't think there's a "default"?

I seem to remember that apple specifically don't provide attestation details on their implementation.

replies(1): >>41865455 #
ndriscoll ◴[] No.41865455[source]
Non-default as in browsers should not provide any attestation information unless configured to via a setting in about:config (which can be automatically enabled by IT on a managed device), and mobile OSes should not provide attestation info to apps unless configured via some similarly buried setting that MDM can enable.

Basically put it there for nerds and IT where the device owner wants that extra security and coordinates with (or is) the service provider to set it up. For everyday use, it should be unavailable so that it's not used for lockin.

replies(1): >>41867301 #
1. growse ◴[] No.41867301[source]
Browsers should follow the spec.

Whether or not attestation data is passed onto the browser is a decision the passkey provider can make.