Hacker News Reader

Comment by reddalo | Hacker News Reader

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.

View on HN

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)

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.

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

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.

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!

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.

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

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

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

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?

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.

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...

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

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)

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.

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

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?)

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

Reply on news.ycombinator.com