Passkey caching setting

@krusnof

To my understanding this is a setting to make it easier and less tedious for you to use passkeys. It basically helps sites when they say I can use a passkey, we use that along with your option to say yes this user has a passkey let's prompt to unlock. In a nutshell it should help avoid constant unlock prompts if every site you visit prompts for a passkey. We'll only prompt for unlocking on sites which you have saved in 1Password.

To me it seems like a good feature to have on.

It might be but this is not something reassuring when they is no support article on it to explain what that means "This may reveal your ownership of passkeys in 1Password". Ownership to who and what's the implications?

I also don't understand the implications when it says "may reveal your ownership of passkeys in 1Password". This is clearly a warning to us users and a disclaimer for 1Password. Is there any information about how this 'passkey ownership in 1Password' vulnerability can (or has) been accessed?

For example, if some bad actor knows this information, would it be possible for them to access the passkey itself and assume my identity?

I believe these are the underlining concerns and questions considered by this post.

Hello folks,

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-42242802

Thanks, @1P_Dave , for the extended explanation. It is much clearer for me now.

Right now, I don't mind being required to unlock the extension in order for 1Password to determine whether or not I have a passkey for the website. Unlocking the extension is one of the first things I do when sitting down to an extended session browsing the internet.

Perhaps I will feel differently if/when I experience this 'clunky' behavior after passkeys become ubiquitous and I find myself browsing with 1Password locked more frequently.

Thanks again for your quick replies and your thorough explanations.

@snoringelephant

I'm happy that I was able to help clarify the setting. 🙂

-Dave