Passkey Lab
The results table below shows two problems that can stop the same passkey from unlocking encrypted data across devices, browsers and connection methods: different encryption keys, and inconsistent identity verification.
In the first problem, using 1Password through local Safari and through Chrome’s phone QR flow produced different encryption keys, despite using the same passkey and input.
In the second problem, Chrome Password Manager behaved differently in Chrome on iPhone and desktop, despite using the same userVerification: "preferred" setting. The iPhone reported successful identity verification; the desktop did not, so the desktop test stopped before reading the passkey’s encryption keys or checking whether they matched. Desktop runs using "required" reported successful verification and completed the comparison.
Each row represents a different combination of PRF creators and consumers. The Creator is the device that created the passkey; the Consumer is the device that retrieves and uses that same passkey. Given the same input, every combination of Creator and Consumer should be able to run PRF and generate matching encryption keys, but our tests found discrepancies.
Reading the keys
This notation shows how inconsistent hashing can produce different encryption keys.
x- The original input given to the passkey.
D(x)- A hashed version of that input, used for comparison.
P(x)- The encryption key the phone returns for the original input.
P(D(x))- The encryption key the phone incorrectly derives from the hashed input.
In the P(D(x)) case, the tested 1Password QR flow behaves as though the input is hashed one extra time compared with local Safari. This produces a different encryption key, preventing data encrypted through one path from opening through the other.
“Pass” means decryption worked out of the box. “Needs changes” means decryption worked after additional configuration.
| Test | Creator | Consumer | Requested verification Creator → Consumer | Creator key | Consumer key | Outcome | Vendor follow-up / proposed fix |
|---|---|---|---|---|---|---|---|
| 01 | iPhone Safari1Password | Chrome · QRiPhone · 1Password | Preferred→ Preferred | P(x) | P(D(x)) | Fail | 1Password, Apple and Google should check why QR returns a different key from Safari for the same passkey and input. The responsible vendor is not yet known. |
| 02 | Chrome · QRiPhone · 1Password | iPhone Safari1Password | Preferred→ Preferred | P(D(x)) | P(x) | Fail | Investigate the same key mismatch when data is encrypted through QR and opened in Safari. Check where the two routes hash the input differently. |
| 03 | iPhone SafariApple Passwords | Chrome · QRiPhone · Apple Passwords | Preferred→ Preferred | P(x) | P(x) | Pass | Apple: no change needed for this tested QR route. |
| 04 | Chrome · QRiPhone · Apple Passwords | iPhone SafariApple Passwords | Preferred→ Preferred | P(x) | P(x) | Pass | Apple: no change needed for this tested reverse QR route. |
| 05 | iPhone SafariApple Passwords | Desktop Chrome · directApple Passwords | Preferred→ Preferred | P(x) | P(x) | Pass | Apple: no change needed for this tested direct route. |
| 06 | Desktop Chrome · directApple Passwords | iPhone SafariApple Passwords | Preferred→ Preferred | P(x) | P(x) | Pass | Apple: no change needed for this tested reverse direct route. |
| 07 | iPhone ChromeChrome Password Manager | Desktop Chrome · directChrome Password Manager | Preferred→ Required | P(x) | P(x) | Needs changes | Google: investigate the earlier desktop approvals that did not report identity verification. This run worked with required verification and matching keys. |
| 08 | Desktop Chrome · directChrome Password Manager | iPhone ChromeChrome Password Manager | Required→ Preferred | P(x) | P(x) | Needs changes | Google: investigate why the default desktop approval did not report identity verification. The stricter request worked and the keys matched. |
| 09 | iPhone Safari1Password | Desktop Chrome · direct1Password extension | Preferred→ Preferred | P(x) | P(x) | Pass | 1Password: this direct extension route worked without changes. The key mismatch appeared in the earlier QR tests. |
| 10 | Desktop Chrome · direct1Password extension | iPhone Safari1Password | Required→ Preferred | P(x) | P(x) | Needs changes | 1Password: check whether this also works with the default verification setting. This run used the stricter setting; it does not prove the default would fail. |
Who needs to fix this? It is not yet clear whether the fault is in 1Password, Apple’s passkey support or Chrome. The QR and direct-extension tests used different websites and passkeys. 1Password’s handling of Apple’s inputs and Chrome’s iOS code are places to investigate; they do not prove which vendor caused the mismatch.
Contributing
Help broaden the evidence with another browser, password manager or access path.
- Include the date, test website, device and software versions. Describe how the passkey was selected on each device: directly, through an extension or by scanning a QR code.
- Record the verification setting and whether each device reported identity verification. Include whether each of the four decryption checks worked, or the exact error if the test stopped.
- Share a summary without keys or passkey identifiers. Copied test data and reports contain these values; remove them before posting publicly.
Share a result on GitHub or read the contribution guide. Explain what happened and label any guesses about why.