The current knowledge base tech essentials covers passwords and MFA. I think adding Passkeys would also be a good idea to promote their usage, and to show a better alternative to passwords. I won’t harp on the privacy and security benefits since they are well known.
It would help get users new to passkeys understand what is otherwise too technical or a blackbox for some.
Not gonna lie, I thought I knew how passkeys work but I actually dont.
This was me a while back lol. That’s why i think its important to dispel myths early on. Especially since passkeys are a better mfa than shared secret setups and can be done offline using stuff like keepassxc and keepassdx (soon 
)
I think passkeys are still too inconsistent of an experience to recommend widely. No one wants to end up in a situation where they cannot log in on a device since their passkey won’t work.
Most services also don’t allow password-less accounts with only passkeys, so the phishing resistance is undermined.
I sorta agree, but I am asking for it to be added to knowledge base covering tech essentials, not recommendations. Passkeys are starting to have wide adoption, and will definitely be the first class citizen in authentication soon, especially in secure and/or enterprise settings. Better people reading the knowledge base are pointed to good resources than get embroiled in misunderstandings about passkeys that are getting circulated in some privacy communities.
My concern is that it’s too varied an experience to effectively give a relevant overview of. For example, the Multi-Factor Authentication category already mentions FIDO2, which is the overarching standard encompassing the WebAuthn standard, which is what passkeys use.
Passkeys can be tied to a hardware token like a YubiKey, they can be used in a cross-platform password manager, or they can be stored in the system password manager. These are different ways to have passkeys, but then come the differences in using passkeys. Some ways include using passkeys as a single-factor to log in to a service, as a second-factor for the services that use FIDO2 for 2FA, or an unholy combination of both.
In essence, it’s a whole mess that I can hardly wrap my head around writing this post. I think it would be exceptionally difficult to write a coherent, accurate, and relevant overview of passkeys in their current state.
Eh, I kinda disagree. The ideas you outlined are similar to passwords.
Passwords can be stored to hardware tokens too, like the HSM in phones. Its used in apps like Keepass DX for database fingerprint unlock.
Passwords too.
Passwords too.
I think this stems from confusion around not knowing the differences between U2F, WebAuthn, challenge response, and passkeys, which is exactly what the article can clarify.
Its actually pretty simple. Allow me to make gross oversimplifications to present a rudimentary version. Assume your account is a box.
You can lock your box in different ways. With passwords, you essentially use a lock with one key. The service provider allows people to try keys to open boxes and may also know your key, which means there is a chance of them leaking your keys through improper storage or malicious servers (if its unhashed). You can also be presented with a fake box which reveals your key.
With Totp, you first lock your account with a key (your password) and also create an agreement with the service provider. The agreement is that unless you tell them the secret word, they won’t open your box even if you have the key (the shared secret for totp generation). But now both of you know the secret word. You can still be presented with a fake box, leaking your key and your secret word.
With passkeys, you lock your box with a special key. The key is made by you, then you split the key in two parts so that only they fit each other and no other key can copy them. Then you lock the box with your key and the provider takes the box away. They also take the other part of the key and attach it to the top of the box. Now if anyone presents you fake box, you will know since the key attached to the box will be wrong. Your box is still protected since only the part of the key you have can be used to unlock it. Since you made the key, the provider cannot actually ever know how to open the box, since they didn’t access or create any secret.
Finally you put the part of key you have into a box with a biometric lock, so that only you can open it or even access it, and this biometric box is the one you can store on device, on password managers, etc.
This means passkeys are something you know (the key attached to the top of the boxes) and something you have (the biometric box holding the other key). The best part is you don’t see any of this. You just click login and it happens voila!
Idk, maybe this helps. Imo passkeys can be adequately explained.
Can you share specific links to these myths that are being circulated, so that we know exactly what needs to be addressed?
One example. I’m sure I can find more if I swim in the swamp of r/privacy.
Here’s another HN discussion with myths around passkeys being inherently centralized, when it is the exact oppsite: The biggest issue with passkeys is that I just can't trust the companies offerin... | Hacker News
Its the same thing as encryption and other security stuff: Most people don’t understand it, so they fear it, which leads them to avoiding it.
Some myths I have seen include:
Honestly passkeys may be the thing that secures vulnerable people like older folks and people less familiar with tech. You just do a google/Apple login, and boom you can sign into any app or website with one click. No fiddling, no remembering, no nothing.
Hope this helps 
This is the first short, simple, straight forward explanation of passkeys that I have see. Thank you!
Yes, you can store your passwords wherever, but you can also trivially copy and paste them to move them, which isn’t the case with passkeys, at least not yet, which is part of why they’re such a hassle.
A password stored in an HSM is worthless because it doesn’t prevent extraction of the password. The concept of using a HSM to store a private key which cannot be extracted does not apply to passwords.
You are right that it’s a gross oversimplification, but I see what you are getting at, and in principle, your explanation is correct. What I am more concerned with is adequately explaining how passkeys work in the context of them being used differently across services (which is continually changing) and how people can use passkeys as seamlessly as possible. Right now, there are few, if any, good solutions.
As Anon said it’s oversimplified and it wouldn’t fit with the writing style of Privacy Guides, so a passkeys section on the site would likely be more detailed than that.
You can trivially move them around using a keepass database. Or cloud sync. Or export them from the cloud like 1Password and store them as a json.
It applies in certain cases, like when hardware keys are used for key creation by adding them to passwords as opposed to implementing challenge response. This would mean the hardware key’s embedded value is used as a key i.e. the password.
Agree to disagree, passkeys seem seamless to me. I think pointing people to passkeys is not a bad idea.
Yeah lol, it was just a discussion point, not a pull request. The actual article should of course follow whatever guidelines PG has.
On a lighter note, I also don’t think this topic is too early, because I am sure passkeys will become standard before PG adds it based on the glacial pace of change here lol. So its perfect timing 