Subdomain support

[WardsParadox]

Hello, Love Bitwarden and have swapped to it from Lastpass. I noticed that there is no support for separating sites based on the full domain. Bitwarden detects tech.example.com and forms.example.com to be the same site and offers both sets of logins for both sites. If a user could setup a URL rule to prevent this, that would be great.

[tmuka]

I agree. I use a lot of subdomains that don't share credentials with the parent domain, it's a hassle scrolling through my list to find the right subdomain. An improvement would be at least putting the exact matching subdomain credentials at the top of the list. Thanks!

[kspearrin]

Today bitwarden will compare the "base domain" when showing you suggested logins.

I am going to propose that we add a boolean (checkbox) option to each login "Use Full URI", defaulting to false. If a login has this option checked we will compare the full hostname (including any subdomains and ports) instead of the base domain.

Examples:

domain.com

domain.com (match) sub.domain.com (no match)

sub.domain.com

domain.com (no match) sub.domain.com (match) sub2.domain.com (no match) sub.domain.com:1234 (no match)

sub.sub2.domain.com

domain.com (no match) sub.domain.com (no match) sub.sub2.domain.com (match) sub.sub3.domain.com (no match)

localhost:4000

localhost (no match) sub.localhost (no match) localhost:4000 (match)

[globau]

looks sane however aswww is a technically subdomain it may need special handling - i would expect www.example.com to match example.com even if "use full uri" is enabled.

[WardsParadox]

Any idea when this will actually make it to the extension? I don't seem to see this in the current release of the chrome browser extension.

[kspearrin]

@WardsParadox It hasn't been started yet. Hopefully sometime soon.

[WardsParadox]

Ah ok. I got misled by the merge. My bad. Thanks for the info 👍

[kmf]

Watching this ...

[guyspr]

Any progress on this? The direct matches on top works well, but I would prefer it if bitwarden would not display all options for a single domain.

[SylwesterZarebski]

@globau commented on 22 maj 2017, 19:41 CEST:

looks sane however aswww is a technically subdomain it may need special handling - i would expect www.example.com to match example.com even if "use full uri" is enabled.

I suggest another option for this - maybe something like: Always handle this subdomain with parent domain: [www] Which could be cleared, because www.doma.in may be different from doma.in, especially in Intranet webpages, where are multiple subdomains and multiple different credentials for each website.

[ChristianMartel]

Today bitwarden will compare the "base domain" when showing you suggested logins.

I am going to propose that we add a boolean (checkbox) option to each login "Use Full URI", defaulting to false. If a login has this option checked we will compare the full hostname (including any subdomains and ports) instead of the base domain.

@kspearrin Don't forget to compare sites that have the same subdomains that could have many users : https://domain.com/app1/... https://domain.com/app2/... http://localhost:8080/app1/... http://localhost:8080/app2/...

I understand that it is not possible to match the "app1" on the .com and on the localhost, but it would be awesome to differentiate "app1" and "app2", like LastPass does.

Thanks.

[kspearrin]

@ChristianMartel Yea, my proposed solution would not work for that since it is not taking the URL path into account. Maybe we need something like "Use Full Hostname" (previous suggested solution) and a "Use Full URI" option (your suggestion)? "Use Full URI" would compare that the current browser URI starts with the stored URI.

For example, if you have stored "https://domain.com/app1" as the URI in your vault and selected "Use Full URI", the following would match:

• https://domain.com/app1
• https://domain.com/app1234
• https://domain.com/app1/something?sdfsdf=sd

Would not match:

• https://domain.com
• https://domain.com/app2
• https://domain.com/app

Also I am terrible at naming things so if anyone has better ideas on the labels for those checkboxes I'll take it :)

[ChristianMartel]

@kspearrin What you are suggesting would be better, but would not fit all of my use-cases. For example, I need to be able to match : https://sub.domain.com/app1/main/page (online main app, production database) https://sub.domain.com/app1test/main/page (online dev app, dev db) localhost:8080/app1/main/page (local main app, production db) localhost:8080/app1test/main/page (local dev app, dev db)

And the same for app2, app3, app4 ...

[kspearrin]

Then you would save your URIs as "https://domain.com/app1/" and "https://domain.com/app1test/" (trailing slash)

[SylwesterZarebski]

Is there (or will be) possibility to add multiple URIs to one credential?

[kspearrin]

@SylwesterZarebski That is not planned at this time.

[SylwesterZarebski]

Thanks, making recognizing stricter with some hosts/addresses should be first priority, i think.

[piejanssens]

@SylwesterZarebski Check out "Equivalent Domains". Is this what you are looking for? https://vault.bitwarden.com/#/settings/domains

[todoleza]

@piejanssens the core issue here is quite the opposite, we need to differentiate between domains that are considered the same when matching. This https://github.com/bitwarden/browser/issues/77#issuecomment-303145336 describes the proposed feature very well.

[piejanssens]

You can also consider allowing /regex/ in the website+equivalent domain fields for advanced cases. Then you can match any URL.

[wolph]

@WardsParadox can you fix the typo in the subject please? For some reason it's annoying me a little ;) s/subdomian/subdomain/g

[WardsParadox]

@WoLpH Yup. Didn't even notice. Would have bothered me too. Hopefully, this feature comes soon as since they introduced the sorted usernames, it has made the 9 logins I use that all share the same main domain, a nightmare.

[sebastian-burlacu]

@kspearrin does your solution take into account sub-pages with similarly named fields? For example, our ticketing application has a login page where I enter my email + password, but then when I open tickets that also have an email field for the customer, Bitwarden will auto fill my own email. If I could match on the full URI (https://ticketing.domain.com/login.html) that would be different from the ticket URI (https://ticketing.domain.com/ticket?id=1234) and would solve my problem.

Also wondering an approximate eta for this issue - it's literally the only complaint I have about Bitwarden at this time :)

[kspearrin]

@sebastian-burlacu Yes, that use case would be covered I believe. Maybe in the next month or two hopefully.

[ghost]

for the love of the gods, please fix this. I have 50+ logins for *.local.lan resources that all show up for every single web login page on those resource, where reality, there is only one valid login for that resource

[ghost]

or is there a work around, with the domain rules section?

[ghost]

@kspearrin In regards to https://github.com/bitwarden/browser/issues/77#issuecomment-332943662 , this is an insanely powerful feature that would great to have. Use case example: In a domain environment, say there is 30+ auth-walled resources. Say all those resources use windows authentication. Say domain policy requires accounts change password every 3 months. Each 3 month password change, I would have to edit 30 different Bitwarden login entries, changing the password from my previous domain password, to my new one.

Edit: Work around could be bulk password updating, and store all those login entries in a single folder. Not as direct, but might be easier to code in

[kspearrin]

@meffect This issue is about subdomains, not multiple domains. Please open another issue if necessary. Also, see https://blog.bitwarden.com/new-feature-equivalent-domains-dd29aa462bb7

[ghost]

Me know, just saw that gem and wanted to touch on it, cause lastpass has the same issue

[ghost]

I read the blog article . just my initial opinion but i'm on the fence about it. It would get the job done but kinda feels like using a feature outside it's scope, and would create somewhat of a maintenance issue in certain situations. and things like 2 factor no workie

[ghost]

For this issue, https://github.com/bitwarden/browser/issues/77 , seem's Lastpass has this functionality now. I love Bitwarden so much more. The 2 factor is awesome, and it's so much faster than Slowpass. Here's is Lastpass's Documentation on how they implemented this feature. Lastpass has a section called URL Rules , separate from Equivalent Domains. I did a quick test and it does work. I added resource.local.lan to the url rules and only 1 login entry showed up in the Lastpass menu for that resource.

Going to quote the link language for point in time persistence:

Does LastPass recognize different subdomains?

By default, LastPass uses the 2nd level domain name to decide if a site's credentials should be autofilled. For example, if you have saved a site with credentials for www.acme.com, then LastPass will consider all of the following URLs matches since they all have a 2nd level domain name of 'acme.com'.

www.acme.com

acme.com

login.acme.com

secure.login.acme.com

You can also choose to have LastPass only offer the logins saved to a particular URL. You can do this by setting a URL Rule with exact host matching. By setting this URL rule, LastPass will recognize any subdomains as part of the URL, and only offer the appropriate logins.

From the example above, if all the URLs shared the same login except secure.login.acme.com, you would want to set a URL Rule with exact host matching for secure.login.acme.com. This would ensure that only logins saved to that URl are offered for autofill or autologin on secure.login.acme.com.

Edit: Hmm. Lastpass has really improved lately... starting to like Lastpass more now

[Attoy]

Is there any news about adding subdomain support on Bitwarden? Not complaining, just asking. I switched from Lastpass and I miss this! :)

[kspearrin]

No news as of yet.

[kobelobster]

This is the only feature keeping me at LastPass. Would make a complete switch as soon as this implemented, because I badly need this.

Thanks for the awesome tool, though!

[Attoy]

@tzfrs Yeah, I'm subscribed to this issue just to know when @kspearrin will add this feature!

[dominicpratt]

+1, really miss this feature coming from LastPass

[psylenced]

I've just recently started making the switch and this is the number one issue for me.

Adding the ability to add servers and/or sub domains and/or paths to not join together is very important.

The company intranet has dozens of servers and applications on those servers that have no relevance to each other at all.

Imagine: testserver01.dev.company.internal/app1 testserver01.dev.company.internal/app2 testserver01.dev.company.internal/app3

So I need to be able to add a list of domains, subdomains and paths to make sure they are not linked.

There needs to be the ability to add a list of servers (with wildcards) so that individual entries do not need to repeatedly be manually configured.

eg.

• *.company.internal
• *.sub.dev.company.internal
• dev.company.internal [x] include first path

Anything that matches those wildcard entries should enforce strict matching.

That being said, there needs to occasionally be a time where this can be configured on a single entry too. An example for this is a finance app where the login is email/password, but there is a 4 digit PIN check every time a transaction is made which is different from the login credentials.

Edit:

Also I note that this is the number one commented enhancement which is important for business and enterprise and the issue has remained open for approximately 12 months with no resolution. This does not provide a good look on behalf of the product.

[c0necto]

@psylenced I absolutely agree on your post.

We are currently switching over from LastPass, and the biggest issue right now is that there is no possibility to have different credentials on a subdomain and subdirectory basis (we need both).

[guyspr]

Exact url matching with a wildcard is a must for password managers imo. It's really bothering me lately since now the options for the same subdomain change order to the last one used at the top. Now I have to read the options every single time to find what I need.

A checkmark for a login with 'exact host match' would be enough. Add wildcard support %.domain.com or domain.com/app1/% and you got it covered.

[SylwesterZarebski]

@guyspr commented on 11 gru 2017, 14:12 CET:

Exact url matching with a wildcard is a must for password managers imo.

I would say regular expressions, because simple wildcards are very limited. Also regular expression is mature technology with great support in JS while wildcards are not.

[psylenced]

That would work, but people who are not programmers would be confused as anything understanding them.

A simple * is what a majority of people could understand and I think would handle 99% of situations.

That being said - if regex were added, it wouldn't bother me - just need something.

[SylwesterZarebski]

It is not so simple, because with wildcards You have to make many assumptions, like: whether * do or don't match dot in subdomain string - both options has problems with it, and You can't have both without more configuration options, and it is only an iceberg tip. Contrary, regular expressions give right powers to user without more complicated solutions at addon side. I understand that for most people, regular expressions are like magic, but most of people do not even need strict or multiple domain support (could be 99%), thus i opt for more elastic solution for the rest = more advanced users. Of course, both solutions are fine by me :-).

[Attoy]

Iirc LastPass use a simple method to define subdomains. If you have an entry from domain.com it works for every subdomain with TLD domain.com. However if you have an entry with test.domain.com; the first entry still works for every subsomain with TLD domain.com but the specific test.domain.com. Shouldn't it be a viable compromise? Dont' get me wrong, I know regex gives advanced users a fine-grained configuration capability.

[piejanssens]

Just a checkbox "Parse regex" could solve the debate between wildcard for noobs and regex for pro's...

[favadi]

Iirc LastPass use a simple method to define subdomains. If you have an entry from domain.com it works for every subdomain with TLD domain.com. However if you have an entry with test.domain.com; the first entry still works for every subsomain with TLD domain.com but the specific test.domain.com.

This sounds like an elegant way to deal with this isssue.

[kdar]

Running into this issue having multiple slack domains. But we definitely need a feature that is not limited to just subdomains.

[Wehrdo]

@Attoy I think that is similar to the behavior that I would expect:

Basically, the "most specific" saved credential gets priority. When you only have credentials for TLD.com, it will work for any subdomain of domain.com. But if you have saved credentials for sub.domain.com, then that is the more specific fitting credential when visiting any host that matches *.sub.domain.com.

With this, the www prefix will not cause any problems, unless the user specifically saves a separate credential for the www subdomain.

I find the subdomain issue crops up a lot, so I think it's an important feature to have handled somewhat automatically, if possible.

[fcartegnie]

Presenting all entries on a shared hosting domain and expecting the user to never leak credentials to another app by always clicking the correct one. What can go wrong.

[kobelobster]

@fcartegnie It's an opt-in option, so you would have to manually activate subdomain support. Per default it would be the same behaviour as it is now.

[zestysoft]

This is also what is keeping me and the rest of my family from switching to (and paying) Bitwarden. I've been using KeePass with the KeePassHttp plugin for this feature. I just have to enable the setting: "Return only best matching entries for an URL instead of all entries for the whole domain."

This shouldn't be a complex thing to solve-- if there are multiple matches in the password manager for a domain and there are entries that have more characters that match the current URL, use that credential instead.

Or just see how KeePassHttp is doing it -- it's open source: https://github.com/pfn/keepasshttp

[hellboyPS]

Really, this should be a key feature in my opinion. I realize, that maybe most users don't absolutely require it, but there are definitely cases where this is needed very much.

I've been trying out bitwarden for close to a month now, and I have to manually type my password more often than not (this is no overstatement). Yes, I might be a special case in that I host a bunch of applications on the same domain (git.mydomain.org, chat.mydomain.org, and so on), but still. There is obviously some demand for this feature.

It also encourages me to use the same password for those different services (different subdomain) which is EXACTLY what I'm trying to avoid with a password manager like bitwarden (rather: use generated random password for each and every service).

So, +1 from me.