> The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them.

Care to cite this statement?

> As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac.

You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.

▲

lapcat 5 days ago | parent | next [-]

> Care to cite this statement?

Yes, literally from you: "Passkeys should never be allowed to be exported in clear text." https://github.com/keepassxreboot/keepassxc/issues/10407 Also, "You absolutely should be preventing users from being able to copy a private key!"

> You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.

But I want to use Apple Passwords. And I do use Apple Passwords for passwords.

What you're saying, in contrast, is that in order to use passkeys, I would be forced to change how I currently store credentials, which is not in iCloud. "You can choose any method you like, except the one you currently like" is a pernicious interpretation of "choice".

▲

timmyc123 5 days ago | parent [-]

You're quoting the first post of a long discussion, where the importance of protecting your data on disk was highlighted, and a proposal was made that at minimum, the default should be encrypting the backup with a user selected secret or key.

> But I want to use Apple Passwords.

You're choosing to use an app that doesn't meet your needs, when there are numerous apps out there that do meet your needs. I'm not sure how anyone is supposed to solve that for you.

▲

lapcat 5 days ago | parent [-]

> You're quoting the first post of a long discussion

"You absolutely should be preventing users from being able to copy a private key!" is the 8th post in the discussion.

Do you stand by these words, or are you now repudiating them?

> You're choosing to use an app that doesn't meet your needs

I am using an app that meets my needs. I don't need passkeys. It's just other people telling me that I need passkeys.

▲

timmyc123 5 days ago | parent [-]

Copy and paste in clear text? Yes, I don't think that's a good idea. Download to disk in clear text? Yes, I don't think that's a good idea.

Years and years of security incidents with consumer data show that this is a really bad idea.

At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key.

	▲	lapcat 5 days ago \| parent \| next [-]
		> At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key. It feels like this stated minimum is not your actual minimum. Consider for example a macOS user keychain. The keychain is encrypted on disk with a user-selected password. But once you unlock the keychain with the password, you can copy and paste passwords in clear text. The keychain is not a black hole where nothing ever escapes. And I have no objection to this setup; in fact it's my current setup. So when you say copy and paste of passkeys in clear text is not a good idea, there's nothing inherent to encrypting credentials with a user key that prevents such copy and paste. There would have to be some additional restriction.
	▲	pseudalopex 5 days ago \| parent \| prev [-]
		> At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key. What should happen if the developers refuse to enforce this?

▲

Dagonfly 5 days ago | parent | prev [-]

Quoting your comments on github [0]

>> There is no passkey certification process

> This is currently being defined and is almost complete.

>> no signed stamp of approval from on high

> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.

Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?

[0] https://github.com/keepassxreboot/keepassxc/issues/10406#iss...

▲

timmyc123 5 days ago | parent [-]

Unclear how this quoted comment relates to what I was replying to (which was about exporting / backing up your credentials).

But I'll respond.

> Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?

If a website were to block your custom software's AAGUID for some reason, you can change your AAGUID.

AAGUIDs in the consumer passkey ecosystem are used to name your credential manager in account settings so you remember where you saved your passkey.

▲

Dagonfly 5 days ago | parent [-]

Well it relates to this sentence:

> You can use any credential manager you choose.

Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.

At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords.

	▲	timmyc123 5 days ago \| parent [-]
		If a website were to attempt to do this, you (or your credential manager) could simply change the AAGUID to match another credential manager.