[programmertote]

Like some folks already commented here, even as someone who has been working in tech for 20+ years, I find Passkey confusing. I understand the key aspect in computer science term, but I don't know how to use it across devices. Another big worry is that if I tie that to a physical key, then I might lose it (because it's physical) and never get it back.

[reddalo]

Exactly, I always refuse to add a passkey because I'm afraid I won't be able to easily login again. Also, I don't want to be locked in to a vendor.

[pas]

use an open source password manager that supports them.

as others mentioned, there's BitWarden (cross-platform, self-hostable), but if you want something simple there's KeePassXC (and you can put the store file on a dropbox shared folder)

[ryandrake]

I resent that I need a special app to "manage" them. I want to know where this key is on my filesystem so I can back it up and edit it myself, not have to use some app to access it. My ssh authorized_keys is just a text file. I can "manage" it with something as simple as vim. Maybe KeePassXC and BitWarden give you that simplicity, if so great!

[VCFundedGenYer]

KeePassXC "supports passkeys" but the website/app that offers the passkey needs to offer it in the correct way for KeePassXC to ingest it. I've found a fair amount of scenarios where they don't correctly let you drop it into them.

[reddalo]

Until I can have all my keys as cleartext in a text file, I won't use passkeys.

[pseudalopex]

KeepassXC gave users this choice. And was threatened to be blocked for it.[1]

[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

[ryandrake]

Yuck. Look closely at the wording: He is trying to counter a "user choice" feature by saying it doesn't have "protection". "File protection." "Protection of the key." Protection from who? From the user, that's who!

This mentality that the user is an attacker, and the software must protect its data from the user. Isn't a passkey ultimately supposed to be my data?

[inigyou]

This is simply the mentality. Everyone who's worth anything (as in money) has it. Everyone who makes anything you own has it. They do everything based on this mentality and will not give it up. Every new specification or policy has provisions to ensure the device is protected from its user. Whether it's age verification (non-California-style), passkeys, or CSAM scanning.

[OkayPhysicist]

The cabal of evil behind the passkey project actively have KeePassXC on their naughty list fore deigning to allow users to access their keys, and specifically included in the standard the means to discriminate between different passkey vault providers. It is the opposite of an open system, and cannot, under any circumstances, be trusted. Do not use passkeys, tell other people not to use passkeys, and make sure to not let shills astroturf conversations about passkeys unopposed.

[SrslyJosh]

This is hard to understand without any references. Can you please share a relevant link or two?

[OkayPhysicist]

Here's KeePassXC being threatened with blacklisting over granting users control over their own data:

https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

Here's the most readable reference to playing favorites on passkey vaults I could find from the FIDO Alliance (the previously mentioned 'cabal of evil').

See Section 2.2: "Validating FIDO UAF authenticator attestations against the configured authenticator metadata to ensure only trusted authenticators are registered for use. "

And Section 2.3: "Verify attestation assertions made by the FIDO UAF Authenticators to ensure the authenticator is authentic and trusted. Verification occurs using the attestation public key certificates distributed via authenticator metadata. "

https://fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fid...

Basically, Relying Parties (the sites you are logging in to) are expected to allow/disallow certain passkey authenticators (the devices or software that hold your passkeys), based on registration and trusted lists. The FIDO Alliance can use entry into those trusted lists as a cudgel to force compliance with the standard. Effectively, the standard is that users must be locked into to proprietary ecosystems, unable to escape.

[spaqin]

Even if I have my Yubikey passkey that's with my house keys, it's annoying to go grab it and connect every time I need to access something. Enabling it on GitHub was a mistake...

[rib3ye]

You can use a passkey that's tied to a Yubikey.

[avh02]

The problem here is i want to have more than 1 yubikey, so if i lose it, all is not lost... I can't do that with the current implementations unless i present N yubikeys to every new account i make. Which makes an off-site backup yubikey impossible. With my current yubikey usage with password store, my "offline" yubikey can be brought in whenever i want to decrypt the passwords, including ones inserted while the key was in storage.

Also yubikeys have limited passkey slots (100, 25 with old firmware)

[pllbnk]

Also, where do I store the backup Yubikey, or any other pass key owning device for that matter? It has to be easily accessible to set up the pass keys, but also safe from accidents like house fire.

There's a strange tension where I want to use pass keys because they are easy to use but also they are easy to lose, so I choose a KeePass synced over cloud and deal with a bit of a hassle by having to copy/paste my passwords.

[preisschild]

I think technically you can just register the public key of the passkey and only need it on-hand for login

[avh02]

Technically i would think so too, but is that how it's implemented? (I legit don't know, but my feeling was always that you had to add them while they're present, especially as there's different passkeys for different sites, to do it offline do you pregenerate 100 keys for each device to assign later?)

[preisschild]

You can register multiple passkeys for a single user, there is no lock in

[mixdup]

a big problem with passkeys is that there is a lot of flexibility in how it is rolled out with a given site or app. Some sites ask your browser for a passkey as soon as you hit the login page. Some sites you need to enter your username/email address first before you're prompted. Some sites a passkey satisfies both password + second factor. Some sites you need to enter your password and the passkey is the second factor. Some sites you don't need a password but do need the passkey + a second factor (usually SMS)

This is on top of the confusion around enrolling passkeys in your device and synchronizing them

I am a big passkeys fan, and use them on every service I can, but they leave a lot to be desired in terms of user experience. Not sure all of them are solvable, either. The platform vendor side can be fixed: vendors can better integrate with each other to make your passkeys available on every device. But, the issues with how they work across sites and applications is probably not solvable

[aPoCoMiLogin]

i don't think you really understand how it works. most implementations are secondary implementation alongside login+password.

how to use cross-device? either use some password manager that supports it (apple/google/1password/keepass/etc support it), or use device that you have on hand most of the time - phone. when the passkey pops up - point your camera and scan the qrcode - you are done. otherwise use dedicated device like yubikey or similar.

really not sure what is hard about that to understand. i'm using android and chrome, so i can use the password manager in chrome, or my phone to scann the qrcode.

my country is using similar authorization for government "profile" (mobywatel - poland) that has similar to passkey implementation. you download the app on your phone, login via login+password (or other), download the certificates, and from now on you can point your camera on qrcodes to login to government websites; it requires pin/code or biometric confirmation on the phone - same as passkeys.