URI matching pattern

Q1. What is the problem that you are trying to solve?
There is no wildcard URI/URL matching. When users save password, they won’t type the URI but save the URL. So, it is logical to have the domain name wildcard search to see the list of matching sites. Additionally, it would be nice to have a feature like Bitwarden to define the best matching strategy per entry or like LastPass to have URL grouping feature like seeing similar domains like googlle.com, google.uk, etc. as the same.

Q2 - Who is impacted?
All the users will benefit out of it. If we have the second feature, admins can group domains and prevent creation of multiple accounts on the same service.

Q3 - Why is it important and/or urgent?
It is annoying to search for the entity you want to use. I saved an entry with the URI of sub.google.com but it doesn’t show it when I am on google.com or other subdomains while all use the same password.

Q4 - What is your proposed solution? (optional)

  • The basic and urgent solution would be wildcard matching
  • Adding the option to the user to chose how to show the URI matching
  • Group similar domains and let the user define it herself

Q5. Community support
People can vote for this idea to show traction:

If you want to sub.google.com to show on google.com you need to put google.com on the url. Having no subdomain (https://google.com) is the same than having a wildcard (https://*.google.com)

1 Like

I know it :slight_smile: However, it doesn’t change the request. Let me give you an example.

I have 3 passwords for site.com but one is for a.site.com, one is for b.site.com and one is the admin password for all sites including *.site.com.

Your solution brings more work + it needs to configure one by one. In case of any changes in subdomains, it doesn’t match anymore.

I’m not sure if I understand your problem.
You said that you have 3 different passwords, so there will be 3 different resources, true?
Then, on the first one you can set a.site.com on the URL field, b.site.com on the second and site.com for the last one, which will include site.com, a.site.com, b.site.com and all the possible subdomains on site.com, doesn’t matter if a subdomain changes

First, it is not my problem. It is a request for a new feature :slight_smile: I tried to come up with a scenario.

Let me try another example which is my issue in the real world. What would be your suggestion for this case? Something user-friendly not a way to solve the issue. I know how to solve the issue but it is not handy.

URI Password
loclahost:123 Pass_1
sub1.site.com Pass_1
loclahost:456 Pass_2
sub2.site.com Pass_2
sub3.site.com Pass_3
sub4.site.com Pass_3
sub5.site.com Pass_3
sub6.site.com Pass_3
sub1.site2.com Pass_3
sub1.site3.com Pass_3
sub1.site4.com Pass_3
site5.com Pass_3

In your solution, there are some issues:

  • What if the domain or subdomain is changed? I work in a very dynamic and rapid changing environment; as the team develops software on daily basis. Plus we are in migration of all products.
  • Why should I spend so much time to adjust URI while it is a basic feature of all password managers?

So how would the ur for Pass_3 look like? site*.com or * ? What about Pass_2 would the URL also be *?

To give you some context, the current rules for URL matching are based on security auditors recommendations. Any phishing opportunity in the suggestion algorithm is considered a vulnerability by security researchers. In other words if it would would be possible for an attacker to buy site8.com domain to setup a phishing attack, this would be considered a vulnerability in the product. So we would need to put that behind a client-side setting.

To answer your question, I tried to show that the setup of our company is a bit dynamic and every time they change subdomain and sometimes they use new domain for test/dev environments. It is too user-unfriendly to go through multiple steps to find the password related to the URI which is not exactly matched with the URI in the entery.

I am a security specialist worked with well-known enterprise comapnies and gov organizations, so I know best practices are very well. But based on the triangle of security, if you would like to increase the security, you definitly decrease the functionality and usability. There should be a balance.

I am currently the user of Bitwarden. In the past, I have also used 1Password, LastPass, and some others for business and personal use.

All have solutions for it and I can’t understand the resitance here :wink:

  • Let the user (as you mentioned on the client-side) make the decision how to show linked password to the entity.
  • Let the password be associated with more URIs. It is the first PM that I use and allows only one URI per entery. Don’t you agree that amazon.com and amazon.uk and amazon.de use the same password? The same for google.com, drive.google.com and so on. So what would be the solution of Passbolt? What you say is to go for wildcard which brings security risks and unncessary extra works for users. I have over 2000 passwords. I need to spend days if not weeks to migrate them to PassBolt. And surprisingly, I need to do it over and over when companies change their login pages.

All have solutions for it and I can’t understand the resistance here :wink:

There is no resistance, we’re discussing why we came to the current design and trying to understand your (and other people) requirements, so we can better define the possible solutions and pick one or more. As you mentioned there are multiple possible solutions.

There is already another request to add multiple URI to a resource:

Another approach we are considering is creating an URL alias list. This would not be linked to the resource but to an account setting (or organization settings).

Let the user (as you mentioned on the client-side) make the decision how to show linked password to the entity.

If it’s different from the wildcard on the resource url, or alias list, then I’m not understanding what you mean. Do you have a link to the documentation of another product doing what your describing?


1 Like

I guess you mean you want something like this:

This looks problematic security wise if credentials are shared, I suspect it’s not an individual setting in bitwarden but applies to all user that have access to the resource?