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 2 days ago | parent | next [-]

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 2 days ago | parent | next [-]

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 2 days ago \| parent [-]
		Until I can have all my keys as cleartext in a text file, I won't use passkeys.

▲

pseudalopex 2 days ago | parent | prev [-]

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

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

▲

ryandrake 2 days ago | parent [-]

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 2 days ago \| parent [-]
		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 2 days ago | parent | prev [-]

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 2 days ago | parent [-]

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

	▲	OkayPhysicist 2 days ago \| parent [-]
		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.