5 ms·

Looks like user error. The domain matching needs to be set if you don’t want it to work on sub domains. The fact Bitwarden does this by default is a wonderful f

Looks like user error. The domain matching needs to be set if you don’t want it to work on sub domains. The fact Bitwarden does this by default is a wonderful feature. So I don’t consider it leaking. Besides if you don’t trust a sub domain you shouldn’t trust the root domain.

mritzmann 6y ago
As Mozilla always says: Default Settings Matter. And here it is even, that Bitwarden ignores my own settings. Bitwarden ignores that Auto-Fill is switched off.
xerxesaa 6y ago
I agree with most of this, but it seems one of the main issues is that it sends it even if autofill is off. I could easily imagine someone overlooking the default setting and inadvertently revealing their password. Also, on what basis is your last statement? There are plenty of scenarios where a subdomain is managed different people, or even different companies. Why should you not trust the root domain if you don't trust the subdomain?
- philliphaydon 6y ago
  I just re-read the thread and realise I completely missed the bit where auto-fill is sent when turned off. That definitely had to be a bug! In regards to the last statement. It’s much rarer now-days for a sub domain site to be owned outright by someone else where they have logs or a deployed website to capture this information. In fact I honestly cannot think of a subdomain where I can upload my own code to. All the sub domains I can think of are just for multi tenant systems so you have to trust the root domain.
  - shakna 6y ago
    Github Pages, Netlify, Surge. Wordpress hosts. All of these have very different people controlling the code on the subdomain, than on the root. The root in many cases may actually be trustworthy, but there's no reason to send them credentials that belong with the subdomain.
  - SturgeonsLaw 6y ago
    Dynamic DNS hosts could have thousands of subdomains under an individual domain, can be registered for free, and those credentials could get an attacker right into people's home networks. An attacker could hide a bunch of iframes in a page and cover lots of bases in one go.
- manojlds 6y ago
  Isn't that why sites like GitHub Pages moved to GitHub.io. Any popular service at this point wouldn't be allowing user content on their main domain.
  - geofft 6y ago
    Not only that, but github.io is on the Public Suffix List, which is designed for this purpose. Any site that allows users to run servers or host arbitrary HTML/JS on a subdomain should ensure that the parent domain is on the Public Suffix List, which ensures that one user can't even attack another. (The other problem the Public Suffix List solves is that "foo.co.uk" and "bar.co.uk" shouldn't be treated like "foo.example.com" and "bar.example.com", even though they have the same number of components.)
    - yorwba 6y ago
      TIL https://publicsuffix.org/list/ https://publicsuffix.org/list/
      - lioeters 6y ago
        Interesting - I'd heard about the reasoning for github.io being separate from github.com, to deal with untrusted subdomains. But I didn't know that anyone could register on the Public Suffix List. The submission process is done via a pull request, described here: https://github.com/publicsuffix/list/wiki/Guidelines https://github.com/publicsuffix/list/wiki/Guidelines
- davchana 6y ago
  Correct, one example of that subdomain is; ca.gov domain is main domain of California Government, and each department of government have their own sub domain here, often at many levels, dmv.ca.gov, CalCareers.ca.gov, calconnect.ca.gov, dgs.ca.gov. All of these 4 have their own account options & passwords. Chrome displays all options on all domains, but on EXACT match, it just shows username, & shows other sub-domains under username, the ones which doesn't match with current dub domain.
belorn 6y ago
A common practice (at least in the past) was universities that gave subdomains to students and student groups. The result is subdomains like studygroups and studentunions. In term of identity, students are part of an university, but in term of security, students are not trusted as much as the university itself. In term of technology it is even possible that the subdomain sits at its own name servers. Even for some of the largest websites on the world like google, I honestly doubt they consider subdomains to be as trusted as root domains. Are every single experimental project at google with its own subdomain as trusted and secure as root?
- jeroenhd 6y ago
  I've had this problem. I used one of my student domains to do research for a course, which required generating a new username and password. Bitwarden's default automagically filled in my uni credentials, which would give access to stuff like VPNs, grades, the whole deal! I've now configured the domain matching correctly, but the default has burned me more often than I'd like.
- geofft 6y ago
  Universities who do this should make sure that .example.edu (or perhaps .students.example.edu or .sites.example.edu or something) is on the Public Suffix List. (I'm hoping Bitwarden defines "base domain" as "one level past a public suffix"; if not, that's a serious bug.) Re trust - in practice, yes, they are, because anything.google.com can read google.com cookies. It's a pretty minor expense for me, a private individual, to register a new domain name: it's an even more minor expense for Google, even apart from the fact that they own .dev and .google and others.
  - anilakar 6y ago
    IMHO the default HTTP trust model where a domain implicitly trusts its subdomains is at fault here, when the logical solution would be to remove the trust altogether or at least make it explicit both ways. With regard to Bitwarden's default behavior to match the whole domain, it's irritating even when it's not a risk. We manage a ton of our systems under the same domain to allow a single 2FA signon before even giving access to the individual services and all the credentials have to be manually set as host-only or they will be autofilled for every other system we're managing.
jbverschoor 6y ago
It's also a user error to reuse passwords, or to 'rotate' them in a predictable manner, or to fill in their password on a phishing site, or to install a password manager which doesn't have secure defaults or even ignore a security setting.
zeeZ 6y ago
I disagree. The default for a password manager should be the most secure, with additional features and behavior only being enabled after the user has had at least the chance to make an informed decision.
- geofft 6y ago
  The most secure is not the most restrictive. A password manager extension has to work. If it doesn't work reliably and people end up copying/pasting passwords, that's not the "most secure".
  - andrewnicolalde 6y ago
    > If it doesn't work reliably and people end up copying/pasting passwords, that's not the "most secure". Why not?
    - geofft 6y ago
      Because one of the security functions of a browser extension (as demonstrated by this very issue) is to ensure that a password for one site only goes to the same site, and not to a convincing-to-a-human phishing site. A browser extension that you can rely on to fill in your password is therefore better for your security than one where you get in the habit of deciding you know better than it and end up copying and pasting passwords and making judgments yourself.
    - fomine3 6y ago
      Input just only for specified (registered) domain name is good for security. If you often use copy and paste, you may not notice you're inputting on phishing site that uses different domain name.
  - zeeZ 6y ago
    Sure, it should work reliably, but it also shouldn't have unexpected dangerous behavior like OP's complaint that the average user is not aware of. It could ship with good defaults and at some point, during setup, some introduction or when relevant conditions are met, ask the user if they want to enable that feature/behavior while giving more information about what it does and potential weaknesses. It doesn't have to be disabled forever or hidden behind some obscure feature flag.
deleted 6y ago
[deleted]
tialaramex 6y ago
Edited: The original example I had here is wrong because of a mismatched TLD. From their own description of the technology (I am not a Bitwarden user) with Bitwarden's default behaviour if you have credentials for the EXA Metal Pole Europe secure website https://example.co.uk/ https://example.co.uk/ it will provide those credentials automatically, without prompting, to the completely different, unsecured site http://cat-jokes.example.co.uk/ http://cat-jokes.example.co.uk/ if any requests to that site are made. Notice that as an on path bad guy I don't need to own example.co.uk or cat-jokes.example.co.uk, I just need to persuade your browser (e.g. with an image link) that it wants to fetch resources from http://cat-jokes.example.co.uk/ http://cat-jokes.example.co.uk/ for which it needs to do Basic auth and Bitwarden will write your example.co.uk credentials to the wire in plaintext. YSOABII. I don't think this obeys the principle of least surprise. I don't think it's a secure behaviour to have at all even for fairly experienced users, and I definitely don't think it should be the default. The safe default is Same Origin Policy which is similar to their "same host" but a bit different. Others have recommended the PSL, and that's certainly less awful than what Bitwarden does now, but it's not good, I certainly wouldn't want Bitwarden to switch to the PSL and then just figure job done and walk away.
- philliphaydon 6y ago
  If you’re hosting a static website on cat-jokes... then any requests made are going to the owners of example.co.uk not to whoever has cat-jokes... It only works if the sub domain grants you some sort of usage on that sub domain. But how many hosts are like that these days?!? One example given is GitHub, but it doesn’t allow you to host serverside code. It’s purely static. Wordpress maybe? But I’ve never used hosted Wordpress so I donno what access you get.
  - tialaramex 6y ago
    The on path attacker isn't hosting the website (static or otherwise) on http://cat-jokes.example.co.uk/ http://cat-jokes.example.co.uk/ indeed with more work the name needn't even "exist" let alone a site. Let's suppose I'm an on path adversary, you're my victim and example.co.uk are a passive third party. You have credentials for https://example.co.uk/ https://example.co.uk/ stored in Bitwarden with default settings I inject any URL into any flow that will cause your browser to try to fetch something from http://cat-jokes.example.co.uk/ http://cat-jokes.example.co.uk/ maybe it's an image URL, or a frame. But that's an HTTP site, so I can intervene when your browser connects and impersonate as cat-jokes.example.co.uk to ask for Basic auth credentials, Bitwarden cheerfully fills them out automatically with your credentials for the secure site https://example.co.uk/ https://example.co.uk/ and sends them plaintext so now I get your credentials. Nothing looks out of place to you, maybe an image or frame was slow to load, but certainly no alerts, no indication anything weird happened.

mritzmann 6y ago

As Mozilla always says: Default Settings Matter. And here it is even, that Bitwarden ignores my own settings. Bitwarden ignores that Auto-Fill is switched off.

xerxesaa 6y ago

I agree with most of this, but it seems one of the main issues is that it sends it even if autofill is off. I could easily imagine someone overlooking the default setting and inadvertently revealing their password. Also, on what basis is your last statement? There are plenty of scenarios where a subdomain is managed different people, or even different companies. Why should you not trust the root domain if you don't trust the subdomain?

philliphaydon 6y ago
I just re-read the thread and realise I completely missed the bit where auto-fill is sent when turned off. That definitely had to be a bug! In regards to the last statement. It’s much rarer now-days for a sub domain site to be owned outright by someone else where they have logs or a deployed website to capture this information. In fact I honestly cannot think of a subdomain where I can upload my own code to. All the sub domains I can think of are just for multi tenant systems so you have to trust the root domain.
- shakna 6y ago
  Github Pages, Netlify, Surge. Wordpress hosts. All of these have very different people controlling the code on the subdomain, than on the root. The root in many cases may actually be trustworthy, but there's no reason to send them credentials that belong with the subdomain.
- SturgeonsLaw 6y ago
  Dynamic DNS hosts could have thousands of subdomains under an individual domain, can be registered for free, and those credentials could get an attacker right into people's home networks. An attacker could hide a bunch of iframes in a page and cover lots of bases in one go.
manojlds 6y ago
Isn't that why sites like GitHub Pages moved to GitHub.io. Any popular service at this point wouldn't be allowing user content on their main domain.
- geofft 6y ago
  Not only that, but github.io is on the Public Suffix List, which is designed for this purpose. Any site that allows users to run servers or host arbitrary HTML/JS on a subdomain should ensure that the parent domain is on the Public Suffix List, which ensures that one user can't even attack another. (The other problem the Public Suffix List solves is that "foo.co.uk" and "bar.co.uk" shouldn't be treated like "foo.example.com" and "bar.example.com", even though they have the same number of components.)
  - yorwba 6y ago
    TIL https://publicsuffix.org/list/ https://publicsuffix.org/list/
    - lioeters 6y ago
      Interesting - I'd heard about the reasoning for github.io being separate from github.com, to deal with untrusted subdomains. But I didn't know that anyone could register on the Public Suffix List. The submission process is done via a pull request, described here: https://github.com/publicsuffix/list/wiki/Guidelines https://github.com/publicsuffix/list/wiki/Guidelines
davchana 6y ago
Correct, one example of that subdomain is; ca.gov domain is main domain of California Government, and each department of government have their own sub domain here, often at many levels, dmv.ca.gov, CalCareers.ca.gov, calconnect.ca.gov, dgs.ca.gov. All of these 4 have their own account options & passwords. Chrome displays all options on all domains, but on EXACT match, it just shows username, & shows other sub-domains under username, the ones which doesn't match with current dub domain.

belorn 6y ago

A common practice (at least in the past) was universities that gave subdomains to students and student groups. The result is subdomains like studygroups and studentunions. In term of identity, students are part of an university, but in term of security, students are not trusted as much as the university itself. In term of technology it is even possible that the subdomain sits at its own name servers. Even for some of the largest websites on the world like google, I honestly doubt they consider subdomains to be as trusted as root domains. Are every single experimental project at google with its own subdomain as trusted and secure as root?

jeroenhd 6y ago
I've had this problem. I used one of my student domains to do research for a course, which required generating a new username and password. Bitwarden's default automagically filled in my uni credentials, which would give access to stuff like VPNs, grades, the whole deal! I've now configured the domain matching correctly, but the default has burned me more often than I'd like.
geofft 6y ago
Universities who do this should make sure that .example.edu (or perhaps .students.example.edu or .sites.example.edu or something) is on the Public Suffix List. (I'm hoping Bitwarden defines "base domain" as "one level past a public suffix"; if not, that's a serious bug.) Re trust - in practice, yes, they are, because anything.google.com can read google.com cookies. It's a pretty minor expense for me, a private individual, to register a new domain name: it's an even more minor expense for Google, even apart from the fact that they own .dev and .google and others.
- anilakar 6y ago
  IMHO the default HTTP trust model where a domain implicitly trusts its subdomains is at fault here, when the logical solution would be to remove the trust altogether or at least make it explicit both ways. With regard to Bitwarden's default behavior to match the whole domain, it's irritating even when it's not a risk. We manage a ton of our systems under the same domain to allow a single 2FA signon before even giving access to the individual services and all the credentials have to be manually set as host-only or they will be autofilled for every other system we're managing.

jbverschoor 6y ago

It's also a user error to reuse passwords, or to 'rotate' them in a predictable manner, or to fill in their password on a phishing site, or to install a password manager which doesn't have secure defaults or even ignore a security setting.

zeeZ 6y ago

I disagree. The default for a password manager should be the most secure, with additional features and behavior only being enabled after the user has had at least the chance to make an informed decision.

geofft 6y ago
The most secure is not the most restrictive. A password manager extension has to work. If it doesn't work reliably and people end up copying/pasting passwords, that's not the "most secure".
- andrewnicolalde 6y ago
  > If it doesn't work reliably and people end up copying/pasting passwords, that's not the "most secure". Why not?
  - geofft 6y ago
    Because one of the security functions of a browser extension (as demonstrated by this very issue) is to ensure that a password for one site only goes to the same site, and not to a convincing-to-a-human phishing site. A browser extension that you can rely on to fill in your password is therefore better for your security than one where you get in the habit of deciding you know better than it and end up copying and pasting passwords and making judgments yourself.
  - fomine3 6y ago
    Input just only for specified (registered) domain name is good for security. If you often use copy and paste, you may not notice you're inputting on phishing site that uses different domain name.
- zeeZ 6y ago
  Sure, it should work reliably, but it also shouldn't have unexpected dangerous behavior like OP's complaint that the average user is not aware of. It could ship with good defaults and at some point, during setup, some introduction or when relevant conditions are met, ask the user if they want to enable that feature/behavior while giving more information about what it does and potential weaknesses. It doesn't have to be disabled forever or hidden behind some obscure feature flag.

deleted 6y ago

[deleted]

tialaramex 6y ago

Edited: The original example I had here is wrong because of a mismatched TLD. From their own description of the technology (I am not a Bitwarden user) with Bitwarden's default behaviour if you have credentials for the EXA Metal Pole Europe secure website https://example.co.uk/ https://example.co.uk/ it will provide those credentials automatically, without prompting, to the completely different, unsecured site http://cat-jokes.example.co.uk/ http://cat-jokes.example.co.uk/ if any requests to that site are made. Notice that as an on path bad guy I don't need to own example.co.uk or cat-jokes.example.co.uk, I just need to persuade your browser (e.g. with an image link) that it wants to fetch resources from http://cat-jokes.example.co.uk/ http://cat-jokes.example.co.uk/ for which it needs to do Basic auth and Bitwarden will write your example.co.uk credentials to the wire in plaintext. YSOABII. I don't think this obeys the principle of least surprise. I don't think it's a secure behaviour to have at all even for fairly experienced users, and I definitely don't think it should be the default. The safe default is Same Origin Policy which is similar to their "same host" but a bit different. Others have recommended the PSL, and that's certainly less awful than what Bitwarden does now, but it's not good, I certainly wouldn't want Bitwarden to switch to the PSL and then just figure job done and walk away.

philliphaydon 6y ago
If you’re hosting a static website on cat-jokes... then any requests made are going to the owners of example.co.uk not to whoever has cat-jokes... It only works if the sub domain grants you some sort of usage on that sub domain. But how many hosts are like that these days?!? One example given is GitHub, but it doesn’t allow you to host serverside code. It’s purely static. Wordpress maybe? But I’ve never used hosted Wordpress so I donno what access you get.
- tialaramex 6y ago
  The on path attacker isn't hosting the website (static or otherwise) on http://cat-jokes.example.co.uk/ http://cat-jokes.example.co.uk/ indeed with more work the name needn't even "exist" let alone a site. Let's suppose I'm an on path adversary, you're my victim and example.co.uk are a passive third party. You have credentials for https://example.co.uk/ https://example.co.uk/ stored in Bitwarden with default settings I inject any URL into any flow that will cause your browser to try to fetch something from http://cat-jokes.example.co.uk/ http://cat-jokes.example.co.uk/ maybe it's an image URL, or a frame. But that's an HTTP site, so I can intervene when your browser connects and impersonate as cat-jokes.example.co.uk to ask for Basic auth credentials, Bitwarden cheerfully fills them out automatically with your credentials for the secure site https://example.co.uk/ https://example.co.uk/ and sends them plaintext so now I get your credentials. Nothing looks out of place to you, maybe an image or frame was slow to load, but certainly no alerts, no indication anything weird happened.