The “Starts with” option is suitable for advanced users who want to manage different scenarios, such as handling subdomains or IP address prefixes. However, there is a security risk associated with this option. For instance, a fake domain could appear as login.iamgooddomain.com.blahblahblah.actuallyiambad.com, potentially deceiving users.
Based on the principle of “Security by Default,” I suggest we combine “Base Domain” detection with “Starts with” detection.
When users select “Starts with,” the following two options should be enabled:
Base Domain (enabled by default, but with an option to disable it)
Starts with
Advanced users will have the option to turn off Base Domain detection if their scenario necessitates it (such as for IP addresses). However, a security warning will be displayed to remind them of the associated risks.
It is not clear how the proposed feature would work. Currently, URI matching uses only a single method (e.g., “Base Domain” or “Starts With”) to determine whether the active tab matches the stored URI. If both methods are enabled, what algorithm would the extension use to determine if there is a match?
… aaand if you had “base domain” and “starts with” combined: then the security risk of “starts with” would vanish because of what mechanism?
PS: It sounds a bit like you assume one must decide the default match detection for all login items. You do know that you can set individual match detection settings for every single URI in every login item, right?
I think OP proposes changing starts-with so that it only matches if both the base domain matches and also the prefix matches. Their goal being to prevent
starts-with http://login.iamgooddomain.com from matching a site with URL http://login.iamgooddomain.com.blahblahblah.actuallyiambad.com
OP then observes this would break starts-with http://192.168.1., which I believe OP proposes fixing by adding another match choice, really-starts-with that retains the original behavior – only requiring a prefix match – but with the added feature of displaying a “Danger, Will Robinson” message at configuration time.
For that attack to succeed, the attacker would have to hijack the DNS queries of their victim (or the DNS servers of googlesites.com, in your example).
Not impossible, but I would say that the convenience provided by base domain being the default option is enough to accept that risk for most people.
That is the well-known scenario, but hosted webapps have introduced another. Notably, Microsoft makes things easy by “As part of creating the website, the site’s URL is assigned a subdomain of azurewebsites.net.” [cite]. In this scenario, base-domain has the risk of exposing creds used on one Azure’s tenants (“customers”) with a website belonging to another tenant. IIRC, I have seen this same “free subdomain” behavior from other hosting providers.
I agree that base-domain is a good compromise for the typical user and therefore keeping it as the “default default” is reasonable.
It’s when one starts to discuss the security risks of match methods, that I feel it worth mentioning that host-match raises the bar a bit further. The idea being that a more precise match results in a smaller attack surface.
I switched my default to host-match a while ago and can report it has worked well for me. I have encountered a few websites that use a different host when registering vs logging in, necessitating updating the URL the first time I using a vault entry. Operationally, this has not proven to be a big burden for me as I prefer the “launch” button to go to the login page anyways.
The place where this paid off is when the whole clickjacking-threat arose. Since I only autofill on accounts.google.com, I am not vulnerable if there were to be a compromise on Google’s other properties (maps, search email, etc).
That’s true, however I would argue that those kind of services won’t be the majority in anyone’s vault.
I myself have a couple of them in my work’s vault.
I just changed those login items URLs’ match detection to host and left the default to base domain.
One thing I don’t like about the default match detection in bitwarden is that it’s a setting that (like all others) is client specific (and not synchronized).
That means that you have to remember to set it on every new client (and on every client that suddenly decides to lose it’s user set-up settings (one of the things that annoys me the most about bitwarden.
At least, if you set it in the vault items you know it should not change all of a sudden.
And, more importantly for me, if that item is in a shared vault it’s not affected by other users’ default match detection of choice (which is not in my control, and will, with a high probability, be the default option).
Another possible solution (which you hint at) would be for it to apply at time-of-creation instead of time-of-use. That is, instead of “default” being one of the match choices on a vault entry, it affects which match choice is pre-selected when creating a new entry.
Not sure which of the two approaches I would prefer, but either would be much better than the status quo.
Yes, you are correct, my intention is to avoid the prefix match that wrongly included other domain (I don’t think all will examine the base domain when using start with).
Let me explain a bit.
Scenario 1:
User go to official website, register account and save the credential in vault, and he used “Start with” to save the credential, domain is http://login.iamgooddomain.com.
Next time when user click the phishing email and go the FAKE website, http://login.iamgooddomain.com.blahblahblah.actuallyiambad.com, the bitwarden match the “Start with” detection and user fill up the password to login.
Scenario 2 (My intention is…):
User go to official website, register account and save the credential in vault, and he used “Start with” to save the credential, domain is http://login.iamgooddomain.com.
Next time when user click the phishing email and go the FAKE website, http://login.iamgooddomain.com.blahblahblah.actuallyiambad.com, the bitwarden will not match the “Start with” detection because the base domain is not match with the record from the vault. Therefore, it will not show any fill up available badge/will not trigger any auto fill function for it.
To conclude, if “Start with” contains a Security risk, then combining domain validation would reduce the level of risk of data exposure. (I know this is all about how user react to it, but the software may also lead the user to the direction).
Sorry. My first impression was, that you meant an or scenario.
But your proposed new matching option aims at an and scenario. And that’s actually not a bad idea, to validate with the base domain. (PS: Though that is the well-known disadvantage of “starts with”.)
@cyrush To clarify the intent of your proposal, I have changed the topic title to “Option to require ‘Starts With’ matching to also match on ‘Base Domain’” (old title was: “Changing the behavior with the ‘Starts with’ in match detection”).
