Exact URL matching + Port number matching filters for credential list

DavidBowring

Please add this, it's a common feature amongst password managers, and absolutely necessary in my opinion. Being presented with 40+ options for a credential because only the main URL is considered is not useful at all!

It also doesn't remember which account was used last against a domain, I would expect the last used to jump to the top of the list.

We are currently testing a business plan for what will be 20+ users, but some of the core features are lacking against cheaper alternatives.

Jack.P_1P

Thank you for adding your +1 @DavidBowring, I've added you as well. :smile:

sspaus

Yep, I totally agree with this. Although this is not a problem for me anymore, it was a huge issue when I used to work for Amazon Web Services. When working for AWS, I used to be presented with all of my personal passwords for my Amazon consumer accounts, then all of the passwords for Amazon Subdomains for internal intranet sites. But the security was so strict that there were many custom URLs that drove me crazy! (Oh, and then they insisted we all use KeePass! Arghhh!) Thankfully I don't have this problem anymore, but this should definitely be a consideration for people who use 1Password at work.

ag_ana

Noted @sspaus, thank you for the feedback as well :+1:

hmijail

Another use case: Zoom recordings that are protected with a password. Their URLs are like https://mycompany.zoom.us/blahblah123xyz , so the domain stays the same but the rest of the URL changes.
I'm surprised that 1Password doesn't deal with this...

ag_ana

Thank you for the example @hmijail, I have let the developers know about it :+1:

mrventures

I came here for this exact request!

ag_ana

Thank you for letting us know @mrventures, noted :)

yorb

Hi, just came here to add my vote and explain a slightly different use case (or maybe this is a bug): I manage a domain with multiple environments, each with different subdomains. For the most part, my environment-specific logins (with their environment-specific subdomains) float to the top of the suggestions for those subdomains and that works great. However, the main production environment has no subdomain, and the suggestions for that page include all of the other subdomains at the top of the list, and the no-subdomain options are at the bottom. :( (EDIT: Actually it looks like they're all just in alphabetical order by subdomain or domain, whichever the URL starts with. So my "demo.p..." passwords are first, then "dev.p...", then "p..." (no subdomain), then "test.p..." etc.)

It seems to me that if the current site has no subdomain, and you have matching logins in 1Password that also have no subdomain, those should be at the top of the suggestions.

Thanks for considering!

ag_ana

Thank you for the details @yorb! I have passed them to the developers as well :+1:

gdhnz

How does 1Password decide what order items are shown as I'm not seeing the behaviour @ag_ana and @ag_chantelle are implying in 1PW8 for Mac.

For a lot of my logins, the correct option is typically the 3rd or 4th item in the list. Usually somewhere after my dev and test logins.

I'd so much prefer an option to use hostname instead of root domain for matches.

[Deleted User]

It certainly is an old issue. I started using 1Password when 1Password 3 released on Windows. My oldest memory is from 1 Password 4 days, I had multiple logins on the same domain. Everything was listed in alphabetical order and that's about it.

It's true that BitWarden has an option to choose how you want to handle the matching for a specific entry and it works well with the browser extension. With the Android app it's a mess due to OS limitations (or Google decisions can't quite remember). Doesn't work right.

Keepass also works on desktop as you can specify the exact URL it needs to match, can even restrict the match to a specific browser, use wildcards etc.

I'm not that bothered as I don't have a lot of logins on the same base domain nowadays but I'm surprised no solution has been found after all these years.

ag_yaron

Hey guys, thanks for the additional input and feedback here.
Please refer to the information I provided to another user in this post: https://1password.community/discussion/comment/619241/#Comment_619241

gdhnz

I already use favourites but my items are still not displaying in the order suggested in that thread.

I'd love the return of the option to always match on subdomain. Using root domain gives too many incorrect options.

gdhnz

At the very least, matched subdomain items should appear before any matching root domain items. Whether they are favourites or not.

ag_yaron

Hey @gdhnz ,

If you have favorites, they will show up at the top of the list even if there are exact matches of the domain and sub-domain.
Try un-favorite your login entries and see if the relevant one shows up first in the list when you visit one of your websites. Make sure that the sub-domain and base domain are identical in the entry's URL to what is presented in your browser's address bar.

In case you're still getting wrong ordering, feel free to send us some screenshots or a video demonstrating this to support+x@1password.com so we can investigate your setup further.

gdhnz

The problem is that I have favourites set for various dev and test system credentials and they're appearing before the relevant prod credentials (also set as favourites) I'm trying to login with because they all have the same root domain but not the same subdomain.

Why are favourites not sorted in subdomain order?

ag_yaron

Looks like the suggestions in the inline menu (that shows up inside/under the username and password fields) are ordered differently than they are in the extension's window.

Can you please confirm that when you open the extension by clicking its icon in your browser's toolbar it orders things correctly (even when the logins are favorited)?

gdhnz

The extension icon list is correct.

The inline menu on the fields is not.

ag_yaron

Thanks for confirming.
I'll forward this to our developers, that does seem like a bug or at least something that we can address quickly :)

ref: dev/core/core#11315

gdhnz

Just an update to say it's not just Safari I'm seeing the issue in. I'm noticing the problem in Firefox (Mac) and Chrome (Windows) although in those browsers, the inline menu seems to be "more correct" than the toolbar button.

ag_yaron

Thanks @gdhnz ,
We've seen the issue on other browsers as well and it was documented :)

RichL

I've been a LastPass user for quite some time, and I would much prefer to use 1password for a number of reasons. However, the inability to match passwords based on a full domain name is something which makes it an impossibility for my company.

We have plenty of internal applications which we put on a subdomain of our company domain, e.g. app1.company.com, app2.company.com. Sometimes even port numbers come into this, e.g. app1.company.com:8080, app1.company.com:8081. 1password stores passwords for these as company.com, and presents all company.com suggestions when you visit any of those apps. In LastPass, I can go to an advanced configuration option and state that company.com should use exact domain matching and/or exact port matching, which makes the problem go away - LP only shows the correct password for the subdomain.

There have been a few threads on this in the past:

• https://1password.community/discussion/87028/stricting-url-matching-for-subdomains (many "me too" replies!)
• https://1password.community/discussion/78850/strict-url-detection
• https://1password.community/discussion/119350/strict-url-matching

The responses previously were that the suggestions still showed the site they were for, which was true for the desktop app, but NOT for the android app - going to any of our sites on android would offer multiple suggestions for "company.com" without any way to discriminate which one you needed. This took it from an inconvenience (on Windows browser it's inconvenient to go to app1.company.com, then scroll down to find the app1.company.com password, but not impossible), to impossible (blindly choosing suggestions which all look the same). Worth noting that this was last checked by me when I evaluated 1p in Jan 2021 - you may have improved the android app since then.

One of the more recent threads had a "our developers are aware of similar requests" but no indication of whether this has changed status internally. I can see this answer which gives some insight into why it's tricky, but it would be nice to know whether this feature is still on a "no, we're not doing it", or has made it to a roadmap.

I raise this again because I'm part-way through a LastPass subscription, and want to know if I should be looking at 1p again when this comes up for renewal.

---

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

recipedude

This is getting increasingly irritating, to the point I'm beginning to consider looking for another password manager even though I have been using 1password for years.

I have searched through 1password preferences assuming there would be some option to resolve this to no end.

Using the Safari Extension, when visiting a site with a login, 1password displays every login matching the top-level domain name. It's brutal and becomes unusable.

For example:

s1.dev.ops.example.com
s2.dev.ops.example.com
s3.dev.ops.example.com
s1.qa.ops.example.com
s2.qa.ops.example.com
s3.qa.ops.example.com
s1.staging.ops.example.com
s2.staging.ops.example.com
s3.staging.ops.example.com
s1.staging.ops.example.com
s2.staging.ops.example.com
s3.staging.ops.example.com
s1.dev.sre.example.com
s2.dev.sre.example.com
s3.dev.sre.example.com
s1.qa.sre.example.com
s2.qa.sre.example.com
s3.qa.sre.example.com
s1.staging.sre.example.com
s2.staging.sre.example.com
s3.staging.sre.example.com
s1.staging.sre.example.com
s2.staging.sre.example.com
s3.staging.sre.example.com

Each of the FQDNs/URLs has a unique login and password (best practices to avoid re-using passwords). Each represents a completely separate website. This list is much shorter than what I typically have configured in reality and there are multiple different base domains across various clients. All of which have different logins/passwords.

When visiting any one of the websites login pages 1password suggests every single login matching the base domain - even though the configured website URL DOES NOT MATCH!

Even worse, often, the first entry in the list that 1password displays, even when there is an exact website/URL match URL doesn't even appear top of the suggestion list.

Searching for a solution through other posts here I found this:

--snip--
1Password will suggest all logins that contain the same base domain. For example, if you have an Apple ID, it will be valid in:

apple.com
support.apple.com
appleid.apple.com
developer.apple.com
etc...
This is crucial behavior, as users can't (and shouldn't) have a different login item with the exact same credentials for each one of these URLs - they are the same website. This applies to a lot of other websites and that is why 1Password will suggest logins if the base domain is identical. However, 1Password should organize the suggestions in a logical manner. It will show exact matches of the base domain + subdomain first, then it will show logins that only match with the base domain (but the subdomain might be different).
--snip--

What!? This is incredibly narrow-minded logic.

Just because a base domain matches doesn't mean "they are the same website." and doesn't mean "users can't (and shouldn't) have a different login item".

Expected behavior:

If there is an exact website match, 1password should display ONLY that match, or multiple matches if one has multiple items matching the exact website.

If there's only one exact match, populate the login fields. Boom now would be a solid UX! :)

Two or three exact matches, show two or three in the list - with a "show more" option that would then show all items matching the base domain.

If there is no match, only then should 1password display the entire list based upon the base domain name be default.

If it is crucial to show login items that do not actually match, why not have exact match configurable in preferences.

More searching and found this from 2017!:

https://1password.community/discussion/comment/348474#Comment_348474

And this thread: https://1password.community/discussion/comment/619247#Comment_619247

It appears safe to say that 1password will not be fixing this anytime soon even though it appears many other users are irritated by this issue.

This comment is disheartening:

This issue has been around since the beginning of time (at least a decade)... do not count on them fixing this. In BitWarden they address this with a drop-down that allows you to select how you want an entry to be matched (domain, subdomain, or full URL).

I guess it's time to move on from 1password and find a solution that works.

Any suggestions on how to stay with 1password? The current URL mismatching is unacceptable.

---

1Password Version: 7.9.1
Extension Version: 70901007
OS Version: macOS 12.0.1

ag_yaron

Hey @recipedude ,
Thank you for taking the time to write to us about this in such detail, much appreciated!

Currently, 1Password's suggestions indeed work in a basic way, but it should suggest exact matches of the subdomain + root domain first, unless you have some of the login entries marked as favorites. The suggestions order is:

• Favorites that contain the root domain (regardless of what the subdomain is).
• Exact matches of the subdomain + root domain.
• Similar matches that contain the root domain.

I tested this in Safari right now using some of the example URLs you provided and it worked as I described above:

Notice the URL in Safari's address bar and see how the first suggestion I get in 1Password has the exact same subdomain and root domain, then it suggests all other logins that contain that root domain.

If that is not what you are experiencing (and none of the login entries are marked as favorites), we can definitely investigate further via email.

Regardless, we do have an open feature request to improve and enhance advanced URL matching settings and better controls in 1Password, so I'll add your voice there.

ag_ana

Hi @RichL!

Thank you for the feedback! My colleague Yaron posted an answer to a similar question just a moment ago, you can find it here :+1:

RichL

I last looked into this issue back in January when I was after replacing my LastPass subscription. I've just created another trial to see what the current state of things is - I'll summarise my opinions below. The two cases which are important to me are Chrome and Android.

Chrome

Using browser extensions (I'm going to assume these are all roughly the same now!), what @ag_yaron has stated above fits - the suggestions are presented with the exact URL match at the top. This is workable, but still a bit inconvenient for the following reasons:

• Irrelevant suggestions are still shown, potentially causing confusion
• When saving a password, need to edit the credential name each time in order to distinguish between them in the suggestion list.

Android

When I previously evaluated this, the main problem was that the suggestion list was not ordered at all. With the current version, the experience is a bit better (I very much prefer the initiating fill from the keyboard suggestions list, this is much better than before). However, there are still 2 critical problems which make it unusable for me at this point in time:

• (Most important) - Credential suggestions are NOT sorted in the same way as in the browser, they're sorted alphabetically
• When saving a credential using the "Create a new login" from the popup suggestion list, there's no option for populating the credential name. Since the credential name is the only way to distinguish between the suggestions, this means that after adding a credential from Android, you then need to launch the 1password app, find the credential you just added, then edit the name to indicate which subdomain it's for.

All of these usability problems would disappear if there was an option for doing strict URL matching for a particular domain. The irrelevant suggestions would not be displayed, and the credential names being identical would not matter since only the relevant ones are displayed. I would not expect this to be in a prominent location of the application to avoid confusing users who won't use it - in LastPass it's buried in Account Settings, for example!

I still hope that in time this will be recognised as an important enough feature for company users and strict URL matching will arrive, and we'll be able to migrate from LastPass.

ag_yaron

Thank you for the additional info here @RichL .

While Android is a completely different beast and has its own OS limitations and restrictions, we do hope to improve things across the board and implement enhanced URL matching controls in the future.

Do let us know if you have further questions or additional feedback to share in the meantime :+1:

[Deleted User]

I see Bitwarden has been mentioned earlier. It does have more matching options but some do not work on Android. If you modify an entry on your desktop because you want it to exactly match a website, it will indeed work very well on desktop but that modified entry will not even show in the suggestions on Android afterwards.

There's an issue on the Bitwarden Github with a lot of valuable input that shows it's not that easy to manage that stuff on Android : https://github.com/bitwarden/mobile/issues/578

ag_ana

Thank you for the update @J.M :+1: