this post was submitted on 11 Nov 2025
290 points (87.6% liked)

Technology

76799 readers
3904 users here now

This is a most excellent place for technology news and articles.

Our Rules

  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots

founded 2 years ago
MODERATORS
L3s@lemmy.world
enu@lemmy.world
technopagan@lemmy.world
L4s@lemmy.world
L3s@hackingne.ws
L4s@hackingne.ws
290
Passkeys Explained: The End of Passwords (sentientrant.com)
submitted 3 days ago by sentientRant@lemmy.world to c/technology@lemmy.world
232 comments fedilink hide all child comments
 

Passkeys are built on the FIDO2 standard (CTAP2 + WebAuthn standards). They remove the shared secret, stop phishing at the source, and make credential-stuffing useless.

But adoption is still low, and interoperability between Apple, Google, and Microsoft isn’t seamless.

I broke down how passkeys work, their strengths, and what’s still missing

you are viewing a single comment's thread
view the rest of the comments
[–] Septimaeus@infosec.pub 2 points 3 days ago (1 children)

Thanks for the great article! I had a question re: the top disadvantage you mention (lock-in).

Background: Although the on-device integration for Apple, Google, etc. use their cloud for E2E sync between devices, it appears KeePassXC using their passkey interception, discovery, and import procedures accomplish the same cross-device passkey implementation without needing a particular vendor cloud lock-in. As best I can tell, this meets the original standard’s sync fabric requirements (whether or not the big providers like it) and relies on platform-specific APIs mostly for interoperability.

Question: If KeePass has been able to implement their own sync this way, and the FIDO standard accommodates non-OS providers (e.g. browsers or PW managers), what is currently the biggest technical hurdle remaining for FOSS-based passkey providers?

[–] sentientRant@lemmy.world 2 points 2 days ago (1 children)

Thank you... and Yes you are right... There could be many reasons like greed or could be risk management if you think from both ends of spectrum. It's sad actually they are developed on the same FIDO2 but insists on being seperate which is weird.... Also they feel that regular user wouldn't be able to set up FOSS passkey provider or may be they lose control over encryption if they share with third party.

[–] Septimaeus@infosec.pub 2 points 2 days ago* (last edited 2 days ago)

Yeah the counter-interoperability of proprietary expansions on FIDO standards sounds a lot like embrace extend extinguish to me. I know engineering standards generally require field revisions but these big corps have a track record of this behavior.

I can see how the FIDO standard’s dID requirement might be an issue at the org level, but even in the case of a fully custom/unknown rooted device they have provisions for using traditional security keys attached to one or more associated devices via USB/BT/NFC. Megacorp platforms might be first to facilitate adoption but the spec absolutely accommodates open provider integration.

I need to experiment with personal security passkey registration and authentication workflows to know how difficult it actually is in practice, but it looks like the equivalent of self-signed certificates are possible anywhere the user controls the stack like self-hosted intranetwork suites that are popular around here.

Thanks again for the write up!