Add confirmation for the Auto-fill option - the exploit suggests the current warning might not be harsh enough?

Feature Requests Password Manager
1

Feature name

Require confirmation for the Auto-fill option

Feature function

Example:

  • When user clicks to enable the Auto-fill option, show a new page. The page repeats the warning, and requires the user to confirm…
  • Confirmation could initially be by ticking a box again (label: “Yes, I want to enable auto-fill on page load”), because…
  • …Flashpoint’s example exploit additionally relied on “Base domain” URI match. There could be a second tickbox “Do not change default URI match detection to ‘Host’”, if the option had still been set to “Base domain”.
  • A final button to apply the chosen settings. This could be something standard like “Apply” v.s. “Cancel”, or “Change my settings”, or even more harshly “Use less safe settings”.

Requiring any confirmation would at least avoid the possibility of “fat-fingering” the checkbox and not realizing the setting was in the “warning” state.

And the harsher the confirmation required, the more it would be clear to the user that BitWarden considered it a serious issue.

I am interested to see more detailed response to this feature request, because AFAICT the following could be a realistic scenario:

  • be a user of one of the relevant hosting services
  • be contacted, e.g. email to [email protected] address, with a link
  • a link click will phish your login instantly, with no further user interaction.
  • the attacker will edit your hosted site to secretly serve their malware to visitors, or replace/insert their own ads, etc.

This scenario requires that you use Bitwarden “auto-fill on page load”. As, the “Warning” currently advises doing so is “generally safe” unless you are not a careful person and visit “compromised or untrusted websites”.

I am also interested in the text of the warning message. But choosing language can be difficult, and I would be interested in requiring confirmation regardless of what the text above the checkbox said.

Related topics + references

Hopefully the following website links that I send you are not “compromised or untrusted”, and you can visit them safely. Take care ;-).

Telling users to ‘avoid clicking bad links’ still isn’t working - UK National Cyber Security Centre.

BitWarden developers response to the exploit as published in Bleeping Computer

The Bleeping computer article correctly links to the public report by Flashpoint. As a new user, I can’t include more than than two trustworthy links here. Feel free to edit a third hyperlink into this post.

“Bitwarden: The Curious (Use-)Case of Password Pilfering | Flashpoint”

“It should also be noted that a brief evaluation of other password manager extensions shows that none of those will auto-fill iframes from different origins or show warnings for iframes from different origins.”

1 Like
2

Actually, no warnings will make this issue go away. You cannot warn the user enough if a feature has been designed in an insecure way.

I can see a number of solutions here, none of which involve tweaking warnings:

  1. When deciding what to fill in, go by the origin of the frame rather than the origin of the top-level document. So if example.com embeds a frame from malicious.com, the latter should receive the password for malicious.com. Obviously, password saving also has to be adjusted accordingly. So this isn’t backwards compatible, but it should be better than leaving things as they are right now.
  2. Only fill in passwords in frames when the frames belong to the same domain as the top-level document. Here defining “same-domain” is non-trivial, and there might still be edge cases where filling in is a bad idea. But it should be mostly fine, and in a backwards compatible way.
  3. Disable autofill in third-party frames altogether, except for a small allowlist of websites where it is known to be necessary. This solves an additional issue: if a website contains a reflected XSS vulnerability, a malicious website can embed the vulnerable website in a hidden iframe, let autofill do its job and steal the filled in password.
2 Likes
3

Being reactive to sensationalistic blogs that overhype corner cases will result in patchwork solutions that are ineffective and unsustainable.

A holistic approach would be more effective, but it is difficult to rationally discuss sensible solutions in an environment of clickbait articles that whip readers into a frenzy over some minor issue.

Using some band-aid to fix the iframe issue will not prevent the same type of credential theft from occurring by XSS (e.g., as demonstrated here and here). As I see it, the underlying issue is that password managers (including Bitwarden) will auto-fill invisible form fields. This issue is not new; it has been known for decades. However, the problem is difficult to solve without breaking functionality. In my opinion, one or both of the following strategies should be explored to mitigate the entire class of attacks based on invisible forms:

  • The browser extension should analyze the visibility of form fields, and only fill fields that are visible. This analysis is not trivial to do, and preventing invisible fields from being filled will affect the auto-fill behavior on two-step login forms (in which the username and password fields are presented separately).

  • The browser extension should count the number of available input fields that will be autofilled using the password field. If more than one such field is found on the current page, present the user with a warning before auto-filling. This will alert the user that there may be a hidden form on the login page, but it will have the side-effect of creating an extra confirmation step when using auto-fill to complete account registration and password change forms. The unwanted side-effect could be avoided by allowing the user to mark specific URIs as login forms (where only a single password field is expected), so that the warning is presented only when multiple password fields are detected on a form that has been designated as a login form.

1 Like
4

I find it difficult to discuss when things get heated, yes. It looks like I caused offence.

I retain my evaluation. I think this thread gathers a lot of relevant information. That was part of my intent.

When I was first reading around and installing BitWarden, I could not find what BitWarden’s warning referred to specifically. Thanks for your suggestion, that part of it is indeed the XSS problem from the Toth link (“You should turn off autofill in your password manager”).

I think the easier no-XSS attack by Flashpoint, is not explicitly included in Toth’s article. (That’s not a criticism, just context.) But I was interested that all the browser built-in password managers avoid the “subdomain” matching, and hence the no-XSS Flashpoint attack. That’s in the table in section 1.1. of Toth.

Safari scores particularly well in Toth’s article. I’d love to know if that extends to the popular Safari on iOS.

It’s also interesting that Android supports password managers at the OS-level. They just block the whole attack class, right? You can’t hide the Android UI element using website CSS. Obviously, all these open-source browsers could be modified to implement a similar behaviour, and/or add an API to benefit all extensions.

5

EDIT: to fill in some of grc’s criticism, about there being multiple cases that we would like to adress:

We have frames e.g. third-party adverts.

We have a subdomain controlled by different person, OR which has an XSS hole.

We have XSS.

Neither of the last two need to use a frame! Toth demonstrated frames+XSS against KeePassXC-Browser only, because for some reason the frame helped hide UI injected by this extension for a redressing attack. This can’t be necessary against Bitwarden, because Bitwarden doesn’t inject any UI (IIRC this is a deliberate choice to keep code simple and auditable).

(Personally, “XSS on literally the same site you’re logged in to” worries me less. I agree it’s bad, but it wouldn’t stop me endorsing a specific password manager if necessary, because it’s a much bigger problem when people inevitably re-use passwords).

This is no slur against Palant, who has advised addressing the first two problems as well as requiring user input :-). (Sections 4, 5, and 7 here: “Password managers: Please make sure AutoFill is secure!”).

6

@sourcejedi

Apologies for my tone in the earlier response. I took no offense to your post, but rather to the authors and publishers of poorly researched clickbait blogs such as the one you linked from Bleepingcomputer (there is another, even more sensationalistic one on the same topic that is now making the rounds on Reddit). Even the original report by Flashpoint (which would have been a much more appropriate reference in your OP as a replacement for the Bleepingcomputer blog) is purely profit-driven and not serving the interest of readers.

 

That’s one of the points I have been trying to emphasize when users are panicking (as many currently are) about this iframe issue. To be fair, your OP does not overly obsess about iframes (which in my opinion are the least likely vector by which this class of autofill vulnerabilities would be exploited). Coming at the end of a long day of posting responses on social media to put the record straight for users who were misled by that poorly written Bleepingcomputer blog, it seems I didn’t read your post as carefully as I should have after seeing the topic title and the Bleepingcomputer link. You did post some ideas worthy of discussion, and I hope that you found the suggestions I included in my response above to be constructive contributions, as well.

 

P.S. I do wish that you would consider replacing the Bleepingcomputer link in your OP with a link to the original Flashpoint report (or permit me to do this for you), as I don’t think that publishers who use fearmongering for profit should be awarded with click traffic.

7

The Bleeping Computer link includes a reply from a BitWarden spokesperson. Implicitly, posting a feature request on the official channel, I was requesting a further response. Specifically to “the following could be a realistic scenario …”

Is there a different response from BitWarden, that you would ask me to link to instead of the one on Bleeping Computer?

The journalism didn’t bother me that much, I guess I’ve learnt to read the whole article (and cross-check sources). I think they provide fair qualifiers after the first three paragraphs… TBH I might have skipped over those entirely :-).

I’m not sure it’s entirely unreasonable to raise iframes as a weak point, with qualifiers included. I see Firefox had to add a fix for frames. …It was basically a single if-then statement for their built-in implementation, however they also have an almost equally convenient fallback, which isn’t the case for Bitwarden :-(.

From context I assume you’re not paid here, but… it sounds like you have been representing BitWarden, in a sense. It’s not unusual for community support forums. If you think you could have found a better tone above, that might reflect better on the project in future. Don’t want to harp on, but for me it made it very stressful either to read and find what the point was, or to reply with any sort of conversational question.

1 Like
8

I have no affiliation with Bitwarden, other than as a customer. I do have certain privileges on this forum which have mostly been bestowed algorithmically by the Discourse forum software as a result of earning a certain level of trust in the community. Bitwarden will stand or fall on its own merits, not on the bedside manners of its community members (present company included).

I do spend a fair amount of time helping fellow Bitwarden users on social media, and I find it frustrating when irresponsible publishers push biased FUD instead of facts, because it steers uninformed users in directions that will actually reduce their security (for example, in response to this latest iframe drama, I have seen users who plan to rely on copy/pasting of passwords as a substitute for autofill, and even users who plan to return to Lastpass. Good grief! :person_facepalming:).

In any case, your OP suggested that you were looking for a “detailed” debate of the substance of your proposals, so with that in mind, any further meta-discussion of media ethics and interpersonal skills would be counterproductive, IMO. Also, to clarify, if you want a response from Bitwarden, you should contact them directly through official channels; in this community forum, comments and feedback will mostly come from other community members (although some Bitwarden staff do also post here from time to time).

On topic — my personal opinion on how Bitwarden should address these vulnerabilites are summarized in the two bullet point in my first response above.

1 Like
9

Thanks, but this is the official channel for feature requests.

I could open (or re-comment?) a bug purely to copy that explanation why I’m so interested in the easy no-XSS “hosting service” case.

If you have a specific idea for what BitWarden developers would be interested in responding to, let me know. But without adding discussion of the warning and how effective it is, it’s hard to see it as anything other than a duplicate IMO, of a report already made by professionals. Noise - like the noise you’ve been trying to reduce in places I didn’t look at.

To the extent that I’m applying pressure, this is the most compliant and non-spammy way I could think of :-).

1 Like
10

Don’t need to use the clipboard if I’m touch-typing three random words! I love that dedicated password managers can generate passphrases, as opposed to line noise.

You can do that without using it to create vault entires, or even without a vault if you use KeePassXC.

I interpret the NCSC public advice as implying “human random” words, as acceptable improvement on common practices. But using a proper generator also comes up with these great phrases, that look like “sadness depleted zone” etc :-).

11

The topic seems to be meandering now, but I will add my thoughts:

Not sure if the above was in jest, or not. Touch-typing is still less secure than a properly configured auto-fill, as it is more vulnerable to phishing (Bitwarden’s match detection rules can be used to make phishing impossible with auto-fill). The “three random words” idea is cute, but it is not very secure (unless compared to the alternative of using transformed dictionary words, like [email protected]!).

 

OK, so it seems that the part of your OP that you are referring to here is the following:

First, Flashpoint never provides any details that would allow the supposed “hosting services” exploit to be analyzed. But let’s assume it works as you’ve proposed. In that case, I would note that as soon as you click on a malicious link, malware can be downloaded and executed on your device without your knowledge. Thus, credential phishing would be the least of my concerns.

Finally, I would agree with Mr. Palant that warnings are ineffective. Bitwarden already warns against several risky actions, and yet the help forum here routinely fields posts from users who got themselves in trouble by not heeding the existing warnings. Even the article from NCSC that you linked in the OP admits that warning users is ineffective.

 

I would propose the following simple alternative to a warning:

In the Autofill Settings, it should not be possible to enable “Autofill on page load” (i.e., this option should be “grayed out” and inactive) unless the “Default match detection” option has been set to something other than Base Domain. Of course, there should be some accompanying explanatory text (e.g., To enable auto-fill on page load, the default match detection option cannot be set to "Base Domain"). If Base Domain matching is still required to get auto-fill to work the way the user wants, then they still have the option to choose this setting on by customizing individual URIs; thus, this proposal does not break any existing functionality, but it will prevent any exploit similar to the purported “hosting service” vulnerability claimed by Flashpoint.

12

I think Flashpoint are clear about their claims. If you doubt the existence of such a hosting service, LMK and I’ll find one. What I filled in is my own risk assessment of it. That could be wrong, I’m not active in security.

Malware links are the reason for NCSC top tip #3, install your security updates. We’ve made 0-days expensive :-). Credential phishing is cheaper.

Security depends on being something people can actually use. That’s why the NCSC moved to blanket public guidance in favour of recording passwords. And implicitly, not stressing about what’s the best manager :-). Personally I suspect they would have been more hesitant if the browsers weren’t providing a reasonable baseline service for free. Not that I rule out supporting BitWarden; I might just endorse my preferred strategies first.

Honestly surprised at some of what you pick up on. I’d think it’s well hashed out, at least that you’d have a link handy to argue why to not horse battery staple.

The secret is most passwords can be weak :-). 3 words is 38 bits of entropy. Trying 2^38 guesses on an online service will get you locked out. My own computer would take 2,000 years to crack my KeePassXC passphrase, which is a lot of electricity to pay for.

If this forum leaks my encrypted password, I’m not trying to guarantee that can’t be brute-forced. The point is I needed to start using unique passwords instead of re-using the same one as on Twitter, because cracking connected accounts on some of these big platforms is a good money-maker for scammers etc.

You might guess that in my case, “something I can use” does involve minimizing residual anxiety. This includes “availability” as well as protection. It depends on circumstances. I don’t assume you want to hear all the special snowflake details of where I am and how I got there. Short extract: no, I personally am not in a position to rely on BitWarden alone to store and enter 256-bit randomized passwords.

(The desktop app doesn’t seem to have a passphrase-protected backup anymore? I saw the docs mention such a feature, but the only encrypted export is by the account key. So it depends on BitWarden continuing to exist. Or possibly relies on them not accidentally logging me out before it ceases to exist. But that’s not more reassuring).

The NCSC top tips are very clearly not a ceiling. The problem is a lot of us haven’t even reached that level. Even though we’ll think about it periodically.

13

I read your post a few times, but it’s a head-scratcher! :thinking:

What I gather is that you are looking for a more secure password solution, but you are unable to use Bitwarden. Something that can be discussed, but it doesn’t seem relevant to your feature request. Perhaps consider starting a new topic in the Ask the Community forum.

Two odds and ends:

  • The password-protected export feature was released in October, 2022, and has only ever been available in the Web Vault app and in the CLI.

  • I don’t doubt the existence of hosting services that host different users on the same domain, but this alone is not sufficient to create a vulnerability. The specific details of the Proof-of-Concept exploit do matter, because only then can one assess the risk relative to other risks faced by users of Bitwarden and other password managers, and only then can mitigation strategies be identified. But for a report to vaguely claim that some unspecified “vulnerability is highly likely to be exploitable on different platforms”, without providing details, is a textbook example of “fear, uncertainty, and doubt”.

14

Like I say, I don’t assume you’d be interested in whether I’m using Bitwarden or not, and whether the exact way I’m using it is “good” or “bad”. That would be a whole lot of details. Thanks for the answer about backups!

Why isn’t there enough detail in the Flashpoint article? I read it and was like, yeah, I now have enough information to perpetrate this myself, under the assumptions

  • we expect we can find such a hosting service
  • I can trick someone into opening a link (which I’ve been joking in this thread about having done so, by including links in my posts here)
  • they were using this (non-default, but suspiciously attractive) configuration of BitWarden.
1 Like
15

Just to avoid being troll-y - my original reply was light-hearted, but I am indeed using 38-bit passphrases for a bunch of accounts now. And feeling very happy about it. Especially compared to previously re-using one password for a bunch of accounts. Which were “low security”, but could have been good scam fodder.

16

This is not sufficient for an attack.

For example, me.blogspot.com and notme.blogspot.com are both hosted on the blogspot.com domain, and presumably belong to different users. However, here, the Sign-In link opens the blogger.com site, and a second Sign-In link there opens a login page on accounts.google.com. Thus, the relevant Bitwarden login item would be the one that contains the google.com URI, and these credentials will not autofill on either me.blogspot.com or notme.blogspot.com.

Very specific conditions would have to be met for an attack as described by Flashpoint to be possible:

  • The service would have to allow different users to control different subdomains on a shared domain (this one is easy — e.g., blogspot.com).

  • The login page for the service would have to be hosted under each user’s subdomain (e.g., mysubdomain.example.com/login).

  • The login pages for the service would have to incorporate one or more iframes.

  • The user would need to have privileges to specify the source of the iframe contents that are rendered on their login page. Alternatively, if the iframe source is not user-specifiable, Flashpoint would have to demonstrate that they were able to compromise the third-party host that is serving the iframe contents, and that they inserted credential-phishing code into the source HTML hosted by that content provider.

  • In addition, for the scenario proposed by Flashpoint to be plausible, one has to assume that the user does not have privileges to modify any of the other HTML source code or scripts running on the login page (because if the user can arbitrarily modify the login page code, then they do not need to bother with the iframe “vulnerability” — there would be other, more robust methods to phish a user’s credentials).

The information provided in the report is not sufficient to determine whether the above conditions are met for the “prominent hosting environment” that was used in Flashpoint’s claimed PoC, and certainly not whether the conditions are met for “similar service providers” that Flashpoint claims to have “briefly research[ed]”.

 

P.S. I would be happy to read the details about your personal situation, and provide my perspective (if you wish to have it) — just not on this feature request thread.

17

I missed the word “prominent” in the Flashpoint article. I hope that’s not caused confusion. I assumed “hosting” meant web hosting, and some of the cheap or “free” web hosts had done the dumb thing. But the first few Google results didn’t help.

I’m almost using one. DuckDNS both only allow login with other accounts like Google, and IIRC added themself to the Public Suffix List on my request.

In general, I remember many similar services not thinking about the PSL.

I haven’t checked whether afraid [.] org is accepting new registrations. But google shows evidence of existing accounts on subdomains of afraid [.] org.

18

Dynamic DNS services are a classic example of unrelated users sharing the same base domain. If your vault contains a login item for a URL on such a service, the URI match detection method should be set to Host instead of Base Domain. Nonetheless, I don’t know whether the conditions specified in bullet points 2-5 (especially #5) in [my post above] (Add confirmation for the Auto-fill option - the exploit suggests the current warning might not be harsh enough? - #16 by grb) would be applicable to Dynamic DNS services.

19

I’m pretty confident afraid [.] org are not allowing users to modify the afraid [.] org login page that I linked to.

The requirements for the subdomain case are “An attacker hosts a specially crafted web page under a subdomain of e.g. a hosting provider, which has its login form under the same base domain.” This doesn’t require using iframes. You just need to provide a form for BitWarden to autofill.

20

Well, the whole point of the Flashpoint report was to claim credit for discovering a supposed Bitwarden vulnerability related to iframes, to provide “breaking news” for their “Threat Intel Blog”.

As I’ve already stated, there do exist vulnerabilities that will affect any password manager that can autofill login credentials on websites, vulnerabiltiies which have been known for decades. We can discuss those, and how they should be remedied (which I attempted to do in my original response), but if the topic of discussion is Flashpoint’s report about Bitwarden’s alleged iframe “vulnerability”, then I think it is reasonable to insist that any proof-of-concept exploit in fact does rely on the use of iframes.