URI matching preference order

Feature Requests Password Manager
, ,
1

URI matching has been discussed a few times before, but I’m still finding challenges with Top Level Domain and Sub-Domain matching.

image

I know that the default URI matching scheme can be over-ridden for each URI you specify within a login, and this is a great feature, however this needs to be set for each password item in the vault that needs a unique setting.

I’d like to propose a feature that might help address this issue for a broader case.

Proposal
Allow a preference order for URI matching.
e.g. First attempt a match on EXACT, then match on HOST, then match on BASE DOMAIN.

Issue:
Considering these example URLs:
a) domain. com
b) workday.domain. com
c) training.domain. com

When “Default URI Match Detection” is set to HOST, passwords already stored as a BASE DOMAIN will never be matched.

This is particularly an issue in larger environments with multiple host services under a single TLD which use common domain logon credentials. I want to use “BASE DOMAIN” for those.

However, for most other internet services, I want to match on HOST.

As I mentioned, I know that the default URI matching scheme can be over-ridden for each password item in the vault, but this feature could help as a general feature for most.

Thanks for your consideration.

2

Perhaps I haven’t understood what you are proposing, but it seems to me that the scheme described above is completetely equivalent to just setting the Default URI Match detection to “Base Domain”.

Suppose that your active browser tab is displaying a form located at https://webmail.domain.com/login/, and you have a vault entry set up as described in your post. For all three of your stored URIs, Exact matching will fail ⇒ Host matching will fail ⇒ Base Domain matching will succeed.

Suppose instead that your active browser tab is displaying a form located at https://training.domain.com, and you have a vault entry set up as described in your post. For URIs (a) & (b), Exact matching will fail ⇒ Host matching will fail ⇒ Base Domain matching will succeed. For URI (c), Exact matching will fail (unless you add the https:// protocol to the URI) ⇒ Host matching will succeed; however, if you had just set the Default URI Match detection to “Base Domain”, this would also have allowed URI (c) to match.

Can you come up with a scenario in which your “preference order” scheme would yield a different outcome than just setting the Default URI Match detection to “Base Domain”?

3

Thanks for your reply :slightly_smiling_face:

The issue is more the other way around from the scenario you described.

Suppose this first scenario:

  • Bitwarden plugin is configured to URI match on BASE DOMAIN
  • My active browser tab is displaying a login form located at https://training.domain.com/
  • I have MULTIPLE vault entries for dozens of different hostnames within the ‘domain.com’ namespace.
    • One of the vault entries has https://training.domain.com/ in its URI list.
    • Other vault entries have their own URIs listed.

Current Behaviour:
When I visit https://training.domain.com/, two things happen:

  1. Auto-Fill loads the last used login for ANY vault entry that uses the same ‘domain.com’ base domain.
  2. Clicking the Bitwarden toolbar button shows ALL vault entries with a hostname that uses the same ‘domain.com’ base domain.

The “issue” here is that the wrong credentials are usually auto-filled, and it’s slightly annoying to have to select / search for the correct vault entry from the toolbar button’s list.
In this scenario, I would like the vault to auto-fill based on an HOSTNAME.

Scenario 2:

Behaviour:
Same as Scenario 1.
In this scenario, I would like the vault to auto-fill based on an EXACT MATCH.

Scenario 3:
If the URI Match settings are instead HOSTNAME, then there is no chance that any BASE DOMAIN match will work.

This is an inconvenience in larger environments (e.g. Google Apps, or internal Enterprise services) where multiple HOSTNAME services authenticate with common domain logon BASE DOMAIN credentials.

Having a “preference order” would (for example) allow Bitwarden to prioritize an EXACT MATCH for a site, then fall-back to HOSTNAME, then fall-back to BASE DOMAIN.

I hope I’ve described this well enough, but please let me know if it’s still unclear, or if I’ve missed an existing configuration somewhere.

4

Let me see if I understand. Below, “Account” means a unique set of login credentials.

Account1 logs in on site https://service1.google.com.
Account1 also logs in on site https://service2.google.com.
Account2 logs in on site https://workday.domain.com.
Account3 logs in on site https://training.domain.com.
Account4 logs in on site https://testserver.domain.com/site1.
Account5 logs in on site https://testserver.domain.com/site2.

In the above context, you currently have a distinct vault item for each account (1-5); the vault item for Account1 uses the URI google.com as its sole URI value, and all other vault items have a single URI that holds the URL text strings shown above.

You wish to have an option that makes Bitwarden identify the URL of the currently active website as a match to the stored URI if and only if the following pseudocode returns a value of true:

if URL == URI
   then return true
   else if host(URL) == host(URI)
      then return true
      else if basedomain(URL) == basedomain(URI)
         then return true
         else return false
      end
   end
end

Is the above a correct representation of your use case and the new feature that you are proposing?

5

Yes, I think that’s accurate, with one clarification (not sure if it’s significant or not).

In my case (for example) I have several Google accounts for different organisations.
Each unique account has its own vault item.
However some of the vault items have several URI values for the different Google services on offer.

Example:
image

Just a comment for clarity:
Your pseudocode correctly maps the preference order that I described in my example. But I see this behaviour working best as a user-configurable setting which allows the user to select their own preference order to match their needs, rather than being hard-coded by design.

Thanks again for your consideration.

6

Can we say that the simplified scenario that I proposed is sufficient for demonstrating how your proposed function would work?

1 Like
7

Yes, the simplified scenario demonstrates an example of how the proposed function would work.

Thanks again for your consideration here :slight_smile:

8

OK. Let’s suppose that the active browser tab is displaying the login form at the URL https://testserver.domain.com/site2, and you wish for Account5 to be auto-filled.

Clearly, there is no scenario under which your Google account (Account1) will be matched here so let’s skip to the others.

When Bitwarden checks whether to match the Account2 credentials to the active login form, it will go through the preference logic outlined above, and first determine that there is no exact match between the active URL and the Account2 URI (so it will proceed to check if there is a “Host” match); next, it will determine that there is no “Host” match (so it will proceed to check for a “Based Domain” match); in this final test, it determines that the Base Domain of the active URL (https://testserver.domain.com/site2) does match the Base Domain of the Account2 URI (https://workday.domain.com). Hence, it will register this as a match, and therefore offer Account2 as one of the options for auto-filling the form.

The same thing will happen with the vault item for Account3: the corresponding URI (https://training.domain.com) will fail the exact and host matching, but will match on base domain. As a result, the credentials for Account3 will also be offered by Bitwarden as one of the options for auto-filling the form.

With the vault item for Account4, the exact match test will fail, but moving on to the “Host” test, Bitwarden will find a match, and therefore will offer Account4 as one of the options for auto-filling the form.

And clearly, when Bitwarden processes the vault item for Account5, it will find a match when comparing the exact values of the active URL and the stored URI. Not surprisingly, Account5 will be offered by the Bitwarden browser extension as one of the options for auto-filling the form.

Therefore, the end result of the preference rules you have proposed will be that when your browser tab contains the login form at the URL https://testserver.domain.com/site2, the Bitwarden browser extension will find four different accounts that “match” (Account2, Account3, Account4, and Account5).

If we perform a similar analysis of what would happen when the active URL represents any of the other login forms in the domain.com domain (i.e., https://workday.domain.com, https://training.domain.com, or https://testserver.domain.com/site1), we would find the same result: the Bitwarden browser extension will always match the credentials for Account2, Account3, Account4, and Account5.

Thus, as I already noted previously your proposed “preference order” scheme will yield results that are identical to what woudl happen if you simply set the URI Macth Detection rule to Base Domain.

9

Why is my boy getting all this hate? He’s right.

I want Host to be prioritized, and then Base Domain if Host returns no options.

I self host a bunch of services where port numbers are relevant, so for those I want Host selected. For a bunch of other things I want Base Domain selected. I do not want to go back and change settings for individual site entries.

The solution to this currently is keeping Base Domain as default and setting Host for all my urls where port matters, but this is annoying.

10

@Aidan_Gibson Welcome to the forum. Please familiarize yourself with our Community Guidelines.

I moved your comment from the thread Base domain versus host: best of both worlds , because it didn’t fit there (that user wanted Bitwarden to create a sorted list of all services for which he had accounts in a given web domain). What you are asking for is more akin to what was requested in this thread.

I suggest that you read through all of the posts above. If you still believe that there is a way to implement what you are asking for that would not simply be equivalent to using Base Domain matching for all items, please provide a detailed explanation or example.

11

2 posts were split to a new topic: URI matching issues