this post was submitted on 12 Oct 2026
267 points (84.7% liked)

Privacy

51408 readers
667 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Related communities

much thanks to @gary_host_laptop for the logo design :)

founded 7 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] skippy@sh.itjust.works 2 points 2 days ago (2 children)

Nice explanation!

Can you elaborate on this part?

some big corporatins would like to control where and how you can store the passkeys

[–] RedGreenBlue@lemmy.zip 5 points 1 day ago* (last edited 1 day ago) (2 children)

Attestation means that whatever code runs on your authenticator has been submitted to the FIDO Alliance (google and buddies) and they signed off on it. After that it can't be changed.

Security keys like the Solokey Hacker (the superior version), is not signed and never will be, cause I can tinker with it in any way I wish. It's truly mine.

Like the article highlights, attestation is part of the standard. The remote service can ask for cryptographic proof that your authenticator, where you stored your passkey, is attested. I have not seen any service doing that so far. IT managers are doing that internally, for their employees for sure. They don't trust bobs homemade solution, only their chosen vendors. From that standpoint it's reasonable.

This gives the service the power to deny you freedom of choice of where to store your passkey. They might say only yubikeys allowed or only microsoft hello or only IOS secure enclave or whatever they wish. It might become a scenario where they don't allow any passkey solution that can run outside their platform. Running LineagOS or Linux? Google and microsoft will say it's "not secure enough".

They will abuse that power to make your decision for you and lock you in. "Password manager not allowed, Use our cloud insted".

Ideally it's not part of the standard and they don't get the option of knowing anything about your authenticator. It's none of their bussines how i choose to store my secrets.

Any sane service will just not ask about the attestation. They don't have to ask. I would not ask my users on my webpage. You can store your passkeys on printed paper for all i care. Although, storing them on a usb/nfc key is pretty damn secure and cool!

[–] skippy@sh.itjust.works 1 points 14 hours ago

I’m trying to reconcile corp IT doing it being reasonable, but it shouldn’t be in the standard. If it’s not in the standard, how would they do it?

[–] LedgeDrop@lemmy.zip 3 points 1 day ago

Very cool, I didn't know about Solokey.

Thanks for mentioning it.

[–] Jayjader@jlai.lu 4 points 1 day ago (1 children)

Personal anecdote to illustrate: the last time I tried creating and using passkeys for my Google account, I got the impression they (Google) would only accept keys coming from either Google Authenticator (their 2fa smartphone app) or something like macos's built-in keychain. No way to give them a key generated using a local, offline service that I could store however I want - it needed to be accessible using, basically, a big corpo['s software] as the intermediary. This coming from how their website would request the keys from my browser (which means mozilla seem to be in on it as well :/).

Given that I currently use a pure file-based password manager that I can move around and switch the keys for as I please, the current state of passkeys feels like a step back in terms of allowing me to control my digital identities.

[–] skippy@sh.itjust.works 1 points 14 hours ago (1 children)

It sounds like your browser is not hooked up to your password manager. I’m not sure how you want it to work if the browser APIs the website needs don’t have the required plumbing.

That does not mean the standard or Google have locked anyone out of the ecosystem.

[–] Jayjader@jlai.lu 1 points 9 hours ago

I dunno, the browser could open a file picker and let me point it towards the passkey, or perhaps let me paste the key contents into a field?

It's been several months since I looked into it, so maybe things have changed since, but I don't see why the browser has to be hooked up to my password manager through a mechanism that seemingly can't be user-piloted nor user-intercepted. How does a browser API require some external third-party software to be installed and configured to work?! It's a public/private key pair at the end of the day, right? Not some novel algorithm, protocol, or whatever. Why can't I simply tell the browser "here is where my existing passkeys reside; place any newly generated ones here as well"? Or perhaps "here is the program to call and here are the arguments to supply when you need to create and/or retrieve a given passkey"?

I don't think I have claimed the standard itself is locking anyone out - let me correct that if I did. I have just not found a way to not be locked out of the feature itself in the products of big players like Google - my Google account(s) being the one service where I feel like I could actually benefit from using passkeys over passwords (not to mention one of those I have seen pushing the "replace all your passwords with passkeys!" messaging).

To be specific, my password manager is http://passwordstore.org/, ("the standard Unix password manager").