[Enhancement Request] Wording for "Allow caching passkey-IDs in local storage" confusing

Hi! :)

I just had a small "debugging" session because 1Password didn't offer Passkeys for Google Login in Safari but instead showed the selection dialog for QR code or hardware token.

Long story short: I had caching passkey-IDs turned off because I didn't want to reveal ownership of passkeys - which feels ominous. Reveal to who? I don't want to give away that I have passkeys to any other site than for which it was created.
Which is how it works, right? Or does the local caching expose it also to different sites?

For me, the explanation makes it not clear that the local storage caching gives 1Password the ability to offer Passkeys when locked and then offer to unlock.

I think the wording could be improved for clarity to something like "This allows 1Password to suggest Passkeys for logins even when locked, enhancing the autofill experience while safeguarding your private key data. This may reveal..." (and then a Learn More link to what is revealed to whom would be nice).


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser: Not Provided

Comments

  • Hello @Damnatus! 👋

    I'm sorry for the confusion. One of the goals of 1Password, and password managers in general, is to avoid revealing any information about the items that you store in 1Password when 1Password is locked. It's why, when you lock 1Password, everything that you store in 1Password is encrypted locally. Because of this security architecture, there is no way for the browser extension to know whether you have a passkey saved for a specific site when 1Password is locked. This can create a clunky user experience where you're prompted to unlock 1Password when a site requests a passkey that does not exist in 1Password.

    The "Allow caching passkey IDs in local storage" feature caches hashed passkey credential IDs in your browser's local storage. This allows the extension to "know" that you have a passkey saved for a particular website even if 1Password is locked so that you can be prompted to unlock 1Password and sign in. The actual passkey itself remains encrypted.

    The threat model to consider is local attackers. Code running on your local system, such as malware, could potentially see the cached passkey credentials IDs. As mentioned, your actual passkeys are still encrypted but the following could be found out by a local attacker on your system:

    • The number of passkeys saved in 1Password.
    • If any websites that you use store passkey credential IDs locally, such as in session storage or cookies, then an attacker could correlate credential IDs in those files with the cached credential IDs from 1Password to learn that you're storing a passkey for that specific website in 1Password.

    I can definitely see how the description could be made clearer and I've passed your feedback along to the team internally. I've also filed an issue to have documentation about this feature added to our website.

    -Dave

    ref: dev/web/support.1password.com#4560
    ref: PB-41040440

  • Damnatus
    Damnatus
    Community Member

    As always a Masterclass in explanation of the intention, function and, in this case, trade-off between security and convenience as well as making me feel heard and taken seriously @Dave_1P!

  • @Damnatus

    Thank you for the kind words and for continuing to provide feedback so that we can make 1Password even better. 😊

    -Dave