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:
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)
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 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
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
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?
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?
What about several devices that use the same credential and are accessed by IP? (like a couple thousand) It would be great to have a single entry for all these instead of 2000 entries.
In bitwarden, the matching applies for anyone that has access to the resource.
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)
However, it doesn’t change the request. Let me give you an example.