[Y-bar]

It’s also an issue that extensions like 1Password are _too_ URL-aware, until recently it tried to use heuristics and ignore subdomains for matching credentials. This meant that we used to get a list of almost a hundred options when logging into our AWS infrastructure. No matter which actual domain used. Someone could have used this vulnerability as part of a phishing campaign.

[embedding-shape]

> extensions like 1Password are _too_ URL-aware, until recently it tried to use heuristics and ignore subdomains for matching credentials

I've used 1Password for years (Linux+Firefox though, FWIW), and this never happened to me or our family. I did discover though that the autofill basically went by hierarchy in the URI to figure out what to show, so if you specify "example.com" and you're on "login.example.com", you'll see everything matching "*example.com" which actually is to be expected. If you only want to see it on one subdomain, you need to specify it in the record/item.

That it ignored the subdomains fully sounds like it was a bug on your particular platform, because 1Password never did that for me, but I remember being slightly confused by the behavior initially, until I fixed my items.

[Y-bar]

It wasn't a considered a bug, it was repeatedly reported to them from us via email and from other customers on their community pages.

Just take a look here for example: https://www.1password.community/discussions/1password/bug-su...

1Password then wrote:

> 1Password currently only suggests items based on the root domain. I can see the value of having 1Password suggest only exact matches based on their subdomain, especially for the use case you have described.

Or take a look here: https://www.1password.community/discussions/1password/sugges...

1Password then wrote:

> As it currently stands, 1Password only matches on the second level domain (i.e. sample.com in your example). While I can't promise anything, this is something we've heard frequently, so I'll share your thoughts with the team.

Now it is:

> You’ll see the item as a suggestion on any page that’s part of the website, including subdomains. The item may also be suggested on related websites known to belong to the same organization.

It's that second sentence which is the problem, they "suggested" by being "smart" items from one AWS domain which ought to have never suggested on another unrelated AWS domain.

In version 8.10 when they added Only fill on this exact host: https://support.1password.com/autofill-behavior/

[pjerem]

Haha and Bitwarden is url aware but not enough.

I work in a company where I have two okta accounts (because hey, why not) on two .okta.com subdomains.

Bitwarden _randomly_ messes up the two subdomains and most of the times (but not always, which seems strange actually), it fills the form with the wrong password. I don’t know why. I know that there is an option to make it stricter on domain matching but you can’t configure it on per item basis, only for the whole vault.

[taschmex]

Every browser-based bitwarden client I have used have the option to choose the autofill option on single items as well as the global default. Find the login item, click edit, scroll to autofill options, where each URI is listed with a gear icon next to it. Click the gear and select the appropriate match type.

For the absolute majority of use cases, "host" should be the default, but i have found uses for both "base domain" and "regular expression" in some special cases.

Normal browser extension Bitwarden Ctrl-Shift-L autofill defaults to the most recently used entry when there are multiple matches, afaik.

[sneak]

You can indeed configure it on a per-item basis. The vault-wide setting you found is just the default for ones that don’t have an override set. Click on the domain/url matching setting in the individual credential and you can change it to exact host match.