Open & Fill mangling URIs - appending query string - garbage or security issue?

volts

Open & Fill is appending garbage query strings to item website URIs.

I created a new Login for this website URI:
https://example.com/blah

Open & Fill launches this URI, with a query-string appended:
https://example.com/blah?abcdefghijklmnopqrstuvwxyz=abcdefg0123456789rstuvwxyz

If the saved website URI already includes a query string, 1Password appends to it with correct & URI syntax:

This URI:
https://example.com/blah?foo=bar

Becomes:
https://example.com/blah?foo=bar&abcdefghijklmnopqrstuvwxyz=abcdefg0123456789rstuvwxyz

Observations:

• It's always a 26-character "name" and 26-character "value" pair.
• The "name" changes each time Open & Fill is used.
• The "value" is consistent for each item in 1Password.
• Editing an item in 1Password doesn't change the "value" for that item.

Questions:

• Am I doing something really dumb?
• At first I thought this was a Quick Access bug, but it's happening in the main app too.
• This happens in multiple browsers
• This does not happen in the browser extension
• This does not happen with 1Password 7

Big question:

• Is there a security problem - what is this information?

---

1Password Version: 80700012
Extension Version: Not Provided
OS Version: macOS 12.3

volts

This is happening with the latest 1Password 8 on Windows also.

PeterG_1P

Hi @volts, 👋 thanks for the question. I'm happy to say there's no security problem here. Also, I admire your eye for detail!

Your points under "Observations" here are correct to my knowledge, as well as the fact that 1Password 8 is appending strings to URLs when you use Open and Fill as you've described. So what's going on here? Let's work through your questions:

Am I doing something really dumb?

Nope. You're fine. 👍

At first I thought this was a Quick Access bug, but it's happening in the main app too.

That's true, and it's by design.

This happens in multiple browsers

This is actually good! It means the feature is working.

This does not happen in the browser extension

This is also true, because the browser extension doesn't need to do it. I'll explain more on this momentarily. Let's go to the big question:

Is there a security problem - what is this information?

No, there's no security problem. What's happening here is that, when you press Open and Fill, the 1Password app passes the string into your browser, which acts as a secret reference to the browser extension to tell it what to fill.

In effect, it's the app's confidential way of saying, "Hey, browser extension. Grab this item off the shelf, and put the username and URL into this particular website." And because of the way this is handled, Open and Fill can do this without disclosing anything about the nature of the item itself - the string conveys no confidential data.

This is the implementation we use to make that functionality work in 1Password 8, and for the most part it seems to work really well (although there are edge cases where websites don't like the appended URL, and won't let a user sign in using login information filled from Open and Fill. This is pretty uncommon so far, from what we've seen, but in this case, the best approach is to fill from 1Password in your browser directly, as you would if you were just browsing around with the extension unlocked and letting it fill logins for you per usual).

And the reason that these URL strings don't appear when you're using the extension is that it doesn't need them, because it's already connected to the 1Password for Windows app and it pulls the relevant information based on the URL you've browsed to. By contrast, Open and Fill is a proactive action taken from within the 1Password for Windows app, sort of the equivalent of saying, "Go to this website and put the login in now, even though we're not currently on the page."

So suffice to say, 1Password isn't accidentally leaking data or anything like that when you're seeing this happening. It's just how the apps provide an informational reference to make sure the right login info gets filled in the site. I hope this is helpful!

volts

Thank you for the detailed response. The communication makes sense.

I'm concerned that you may be dismissing a privacy & tracking issue.

Because the sent "value" is durable and consistent, it becomes an identifier.

It leaks that I'm using a specific saved item. It is a great way to identify and de-anonymize me specifically.

And the sent "value" stays the same when sharing an item to another user, revealing the relationship between us.

This isn't limited to logins. This information is sent when filling a simple form field or opening a website with no fields at all.

If I use 1Password to visit http://gov.ru those visits can be specifically correlated to me.
If I share my vault with other members of my team of journalists, our relationship can be seen.
This is dangerous!

volts

I may be looking at this wrong, of course. And I look forward to understanding it better. Now I'm just rambling & making assumptions & guesses:

Is there any reason the query-string values are durable? I'm hoping they are generated randomly, not derived from the item's contents or a static ID. It seems like they only need to be valid until the browser sees the address (and could be invalidated), or maybe for a few seconds?

Obviously it would be nice not to pollute the URI with this stuff at all. :-) It's "rude" and ugly and does break some sites. Would it be possible to avoid sending it for items with no "fillable" fields?

Is the mechanism that 1Password 7 used with the Safari extension not viable? I'm guessing it used macOS and Safari-specific stuff and wasn't very portable.

I assumed modern 1Password could use the fancy Rust core to pass messages, even simple data flags like "autofill with this item". I don't have any sense of how frequently the browser plugins communicate with the core, but I assumed it was often, since password changes are detected immediately.

volts

The value being sent is the (static) unique identifier (UUID) of the item stored in the vault.

It's searchable in the iOS mobile app, and it's part of any Private Link created for an item.

@PeterG_1P can you take a look again?

Jack.P_1P

Hey @volts:

Thanks for your additional feedback. While I can't promise anything, I've shared your specific concerns about de-anonymization with our product team.

Jack