Passkeys: signing in without a password, explained
A passkey is not a password without letters, it is a key pair. What that means, why phishing fails against it, and where the catch is.
You know the ritual: invent a password, forget the password, reset the password. Passkeys are meant to end it. The word sounds like marketing, but there is solid cryptography behind it, and you can understand it in a few minutes.
What a passkey actually is
A password is a shared secret. You know it, the service knows it. That is exactly the problem: something two parties know can be lost in two places. A passkey works differently. When you set it up, your device generates a key pair. Germany's federal security agency, the BSI, puts it like this: your device stores a secret key in its internal memory, and a matching public key is created and stored with your online service.
The private key can sign, the public key can only check that signature. When you log in, the service sends a random challenge, your device signs it, the service verifies it against the public key. Done.
The crucial part: the private key never leaves your device. The W3C specification says so explicitly, the credential private key is "expected to never be exposed to any other party, not even to the owner of the authenticator". You only unlock it, with a fingerprint, your face or a device PIN.
Why phishing fails against it
This is the real gain, often filed under "more convenient", which undersells it. A passkey is firmly bound to the address of the service it was created for. In the jargon that service is the relying party. The credential "can only be accessed by origins belonging to that Relying Party", the W3C writes, and this scoping is enforced "jointly by conforming User Agents and authenticators". By your browser and your device together, not by your attention span.
Translated: if you land on a convincing fake, nothing happens. Your browser finds no matching key for that address. There is nothing to type and nothing to give away. The BSI puts it this way: even if a phishing email did lead you to try to log in on a fake website, the secret key is never revealed.
The catch: synced or device-bound
This is where it gets interesting, and where most explainers go quiet. Passkeys come in two flavours. The FIDO Alliance distinguishes them like this: passkeys synced between a user's devices via a cloud service are "synced passkeys", and those that "never leave a single device" are "device-bound passkeys".
Almost everything you use day to day is the first kind: iCloud Keychain, Google Password Manager, your password manager. Convenient: new phone and everything is there. But it shifts the trust. Andre Büttner and Nils Gruschka of the University of Oslo wrote this up properly in 2025: synced passkeys cannot provide the full protection "since the key must be accessible to passkey provider software to be shared between devices". And further: "The security of synced passkeys is mainly concentrated in the passkey providers as a trusted third-party service." If the provider is vulnerable or acts maliciously, a user's credentials may be completely unprotected. As evidence that this is not theory, they point to the LastPass breach of 2022.
| Property | Password | Passkey |
|---|---|---|
| Does the service know your secret? | Yes, as a hash | No, only the public key |
| Phishing possible? | Yes | No, bound to the address |
| If the service is breached | Attackable | The public key is worthless |
| If you lose your device | The password is in your head | You need a backup or cloud sync |
| Trust in third parties | Your password manager, if you use one | With synced passkeys: the provider |
The second catch is losing your device. With a password you still have your memory. With a passkey you need a plan. The BSI says it plainly: after loss or theft you can recover your accounts if you either made local backups or your passkeys are synced to a cloud. Without backups it can, in rare cases, happen that you cannot log in.
How PriChat uses passkeys, and why differently
With us the passkey does more than log you in, and there is a reason. Your data is encrypted with a key derived from your password that lives only in memory. A pure login passkey would miss the point: we could let you in, but your messages would stay locked.
So we use an extension of the standard called PRF. It returns the same random value for the same input, but only when the real passkey is present and you have verified yourself. MDN describes exactly this use: it can generate a symmetric key for encrypting sensitive data "that can only be decrypted by a user who has the seed and the associated authenticator". From that value we derive a key and wrap your actual data key with it. Our server only ever holds the wrapped package, ciphertext without meaning. It never sees the PRF value or the key derived from it; those fields are stripped before anything reaches us. This is deliberately not key escrow: without your device and your verification the package is worthless, to us as well.
What honesty requires here. First: the password does not disappear with us. It remains the anchor the data key grows from, and you have to enter it once when setting up the passkey. Our passkey is convenience plus hardware binding, not a full abolition of the password. Second: not every authenticator can do PRF. If yours cannot, you stay on password unlock. Third, the sentence we write in every one of these articles: our app is not open source and has not been independently audited. That we stick to the standard, you must take on trust. With Signal you could read the source code. That is a genuine advantage, and we are not talking it down.
A password is a secret you can pass on, so you can be talked out of it. A passkey is a secret your device will not hand over, so there is nothing to be talked out of.
What this means for you
Passkeys are better than passwords, and not by a small margin. The BSI has explicitly recommended them since October 2024, though back then only 18 percent of respondents used them and 38 percent knew the term. Start with the accounts that hurt when they are gone: email first, then everything hanging off it. Think through in advance where your passkeys live and what happens if that device or that account disappears. And keep in mind who you are trusting: with synced passkeys that is not only the service you log in to, but also whoever keeps them for you.