Allow to disable browserpass for http basic auth

[allo-]

I'd like to be able to disable browserpass for HTTP-Auth. Since the last upgrade, which introduced the new dialog for http-auth, it always gets in the way and requires a bit of interaction just to tell browserpass that I do not want it to fill in the password from pass.

I guess browserpass only opens the dialog if there is a password stored for that domain. In my case, it finds a password that has nothing to do with http-auth and probably has no way of knowing that I don't want to use it for http-auth. On the other hand, I still have the http-auth password stored in Firefox and use it from there.

Previously, I had to enter the master password in the first dialog and just hit enter for the second one when I opened the page as one of the first in a new session. Now I get the browser pass window first, which I have to close before I get the other two dialogs. Also, the browserpass window is floating and not clearly associated with the tab, unlike Firefox's tab-modal login dialog. HTTP-Auth never had the best UX, but the current doorhanger of Firefox itself is quite okay.

Having mixed password stores is not a problem on web pages, as I use the hotkey to insert passwords from browserpass and the context menu of the password field to insert passwords from the Firefox store, so they don't interfere with each other.

I suppose the current extension API doesn't allow to check if Firefox itself has a password stored, and probably doesn't allow to use a similar tab-modal doorhanger dialog, so I think the best way to solve this problem for me would be to have a switch if browserpass should be used for HTTP auth or not.

Related: #374

[max-baz]

Thanks for the additional context! I might be overlooking this, but just to explicitly ask, could you consider an alternative where you'd actually move your credentials into browserpass, and describe how that would look? Besides the initial migration effort, then you'd get just one dialog to choose credentials (the browserpass one), so there won't be multiple dialogs to go through? The fact that browserpass can't bind the floating window to the tab is definitely a point against the built-in FF password manager, but besides that, is there any downside to migrating your passwords to browserpass, since you are using this extension anyway?

[allo-]

I'm not quite sure. I have currently a wild mix, of which some passwords are migrated one by one to pass, but in the end there are two use-cases which work quite well by having the default unlocked Firefox password safe and the more secure pass store.

The http auth that I am using are mostly on sites that are guarded against bots. That means there runs a webapp with credentials in pass like I try to migrate most of my password there, but behind a simple http auth in addition that stops random bots from brute-forcing or searching for exploits. The Firefox password manager unlocks on the first access and for the next few sites it is mostly pressing enter one time to unlock for the full browser session. If you want so, it's kind of like having to access internal systems by a VPN even though they are password protected themselves, only that http auth is a bit weaker but more accessible.

The other question is the UX of the dialog itself (what may warrant an own issue if there are ideas). I am not sure about it without having used it for some time, but my first impression is that there is still room for improvement, even though I do not know how much is possible. I am a bit surprised that you can intercept the default http auth dialog at all.

I make another bug for the UX issues I've had on a test with a site that has no credentials stored in Firefox itself: #378

[max-baz]

When you say that you mostly use http auth to guard against bots, it makes me think that a simple toggle to fully disable this feature in browserpass might not be desirable, because this will prevent you from using browserpass on the sites where basic auth is used for "more secure" kind of access.

I'm also not sure that it makes too much sense for us to design for workflows where we intentionally promote weaker security, or try to work nicely in combination with other password managers 🤔 It is made to work with password store after all...

Have you considered e.g. to create a second pgp key, one that is protected with a very short passphrase (or no passphrase at all), and use that one for all your less-secure entries? That would make it both easy to use, and you reap the benefits of having all your credentials in one place?

[allo-]

Hmm, what I'd like to have in principle is a hotkey "Insert from pass", but I think that doesn't work in the Firefox dialog.

I've thought about if it may work to clone that dialog especially to address the issue with one-off login and with searching for passwords. Like having the search field and the found entries on top, then username/password below it reachable with tab and the original Firefox dialog reachable by pressing esc.

I currently use pass like having a shared repository of most passwords and the Firefox store to have device-local passwords. In principle pass is the better way as it is portable between browsers and can be synchronized more flexible, so the two questions are migrating more passwords into pass and the usability of the new dialog, especially related to replacing the workflows for pre-filled passwords. This may be related to web pages too, but I disabled the prefilling for Firefox too for security reasons (signon.autofillForms=false) anyway.

For the question about a secondary key I need to look into how to make pass use two keys in the same repository (in different is easy) and how to make gpg-agent to remember one passphrase for longer than the other. For the less secure passwords I like the Firefox approach to unlock the store one time per session.

The old Masterpassword+ extension had some great options for that, but such deep integration is no longer possible.

[patgmiller]

To my knowledge, once the basic auth opens, nothing external can interact with it. Injection scripts are not permitted inject into 403 auth required, or any http error response for that matter. It has to be an automated callback promise response to the chrome.webRequest.onAuthRequired event.

This is exactly why, we had to switch from the old approach, chrome completely removes it; There is one exception, but it is only for the corporate one where the company has a domain controller / policy required installed extension. That is the only instance which chrome allows the blocking auth method.

[allo-]

Oh, I thought (without looking into the code) you're injecting your own authentication headers. Is that not possible? I think uMatrix injects custom Content Security Policies, so I thought extensions can do this with arbitrary headers.

[r7l]

As a long term user of your extension, i'd also like to have an option to disable Basic Auth popups. It causes more issues then what it helps. Otherwise the extension was and still is awesome. Happy to have it.

The floating window popup is not great if you don't have a floating window manager (like Windows or MacOS). I am using a tiling window manager and even if i could configure this floating window to fit in, i don't want to. I'd like to not have it in the first place. Even on floating window managers (Gnome), it will show up left of the browser window instead of being on top of it.

In relation to the promote weaker security statement, i don't see where you would do any of that. There wasn't any support for this kind of popup so far. And there are situations where Basic Auth is still a valid and good thing. Sure, a VPN fortress would always be the better option but in some instances it is not an option.

For example: When working in web development, you need to have test environments for the clients. Mostly those would contain the same data as what is presented on their public website, just with additional new features. You would at least add Basic Auth in front of it to prevent the testing environment to be indexed from search engines like Google (and considered duplicated content for SEO). If i would ask them to install a VPN on each of their employees computers just to be able to test new features, they would simply move on to another developer.

Anyway, i fully understand the use for this feature. It's just not a feature for everyone.

[allo-]

@r7l I think the "promote weaker security" part was addressed at me saying that the advantage of using the builtin password manager for some workflows is, that other than the (default) gpg-agent, Firefox keeps its own password safe unlocked for the full session.

Reading the part again above, I think I also disagree that integrating nicely with the Firefox password manager is a non-goal. I see the rationale not supporting all combinations with other password managers, but the builtin password manager is a core Firefox feature and many people migrating to pass or using pass in addition may still have many passwords in there.

I think any functionality that actively conflicts with the builtin password manager should have a off-switch. Preferable are of course passive solutions like having the pass login behind the shortcut or toolbar button where it is easily accessible and can co-exist with the builtin password manager without any of two having an disadvantage.

[r7l]

Sorry, i might have got the security comment wrong then.

I am not using Firefox much currently. This might change in future once Chrome will remove support for adblockers even further. For this reason, i can't comment much on the builtin password managers as i am not using them in Chrome nor Firefox. But i also don't think this extension should mix in with the buildin password managers. This just adds another location to take care for your passwords.

It would just be a nice feature to be able to turn off the additional basic auth window coming from Browserpass. So pretty much what the title of this issue suggests.

[Dominiquini]

I am having a problem with this extension and I think it is related to this issue. and probably an option to avoid this extension of interacting with auth_basic would solve:

I need to disable the extension before opening any URL with basic_auth (I have some local services that use it!)

I could use the browserpass extension to fill the password, but it's not working!

Thanks.

[max-baz]

Could you please check if this is a permission issue? See another thread starting from this message and below. If that doesn't help, let's track this in a separate issue, it's a bug that I wouldn't consider being "solved" by removing the functionality altogether.

[patgmiller]

I am having a problem with this extension and I think it is related to this issue. and probably an option to avoid this extension of interacting with auth_basic would solve:

I need to disable the extension before opening any URL with basic_auth (I have some local services that use it!)

I could use the browserpass extension to fill the password, but it's not working!

Thanks.

@Dominiquini no one can fill the basic auth form with browser pass once the form has been opened, see here https://github.com/browserpass/browserpass-extension/issues/377#issuecomment-2828006644

If you however added your local services to the password manager they would show up as an option to select/click in the extension modal popup in your first screen shot.

[Dominiquini]

Could you please check if this is a permission issue? See another thread starting from this message and below. If that doesn't help, let's track this in a separate issue, it's a bug that I wouldn't consider being "solved" by removing the functionality altogether.

All the permissions are granted!

I am having a problem with this extension and I think it is related to this issue. and probably an option to avoid this extension of interacting with auth_basic would solve: I need to disable the extension before opening any URL with basic_auth (I have some local services that use it!) I could use the browserpass extension to fill the password, but it's not working! Thanks.

@Dominiquini no one can fill the basic auth form with browser pass once the form has been opened, see here #377 (comment)

If you however added your local services to the password manager they would show up as an option to select/click in the extension modal popup in your first screen shot.

I don't have the credentials for my local services on the password manager (pass). Maybe this extension could avoid trying to fill credential when none are found in the database!

** I don't added then because I have multiple local services with different credentials, and I don´t know if pass will be able to differentiate between then, since all of then has the same host and only change the subdomain (localhost/####) or port (localhost:####).

Thanks.

[max-baz]

If you however added your local services to the password manager they would show up as an option to select/click in the extension modal popup in your first screen shot.

@patgmiller isn't it weird that the window on the first screenshot says "Loading available logins..." as if it's stuck or broken, as opposed to showing an empty list of entries, with the current domain filter, on which you could press backspace and search for some other entry - like in a normal popup? Is it a known bug?

** I don't added then because I have multiple local services with different credentials, and I don´t know if pass will be able to differentiate between then, since all of then has the same host and only change the subdomain (localhost/####) or port (localhost:####).

I suppose one simple way to differentiate would be to store such credentials in a localhost folder and give files recognizable names, like localhost/someapp.gpg - then it's easy to know what to pick in the popup.

[patgmiller]

@patgmiller isn't it weird that the window on the first screenshot says "Loading available logins..." as if it's stuck or broken, as opposed to showing an empty list of entries, with the current domain filter, on which you could press backspace and search for some other entry - like in a normal popup? Is it a known bug?

I missed that detail, I don't think it normally has loading as if it's stuck. Normally it would just have the search with an empty list and the Add credentials button. Like this below.

So there might be a bug there.

@Dominiquini would you be able to add some items to a folder localhost and see if they even show or not?

[patgmiller]

@Dominiquini what Linux distribution and windowing manager are you using? I'm just wondering if we can reproduce the possible bug with it showing "Loading available logins"

[Dominiquini]

@patgmiller isn't it weird that the window on the first screenshot says "Loading available logins..." as if it's stuck or broken, as opposed to showing an empty list of entries, with the current domain filter, on which you could press backspace and search for some other entry - like in a normal popup? Is it a known bug?

I missed that detail, I don't think it normally has loading as if it's stuck. Normally it would just have the search with an empty list and the Add credentials button. Like this below.

So there might be a bug there.

@Dominiquini would you be able to add some items to a folder localhost and see if they even show or not?

Apologies for the delay. I tried to add login and password in the pass, but it was no use! I clicked on the browser icon for the extension and appears that it are trying to search a entry "f298f455-25b2-4570-b0ce-5905d9f674f2", but the url entered was "http://localhost/Files"

@Dominiquini what Linux distribution and windowing manager are you using? I'm just wondering if we can reproduce the possible bug with it showing "Loading available logins"

Browser: Firefox 138.0.3 (64-bit)
Operating System: EndeavourOS 
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.00GHz
Memory: 33,5 GB of RAM
Graphics Processor 1: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2

Thanks

[patgmiller]

So @maximbaz it looks like the issue in @Dominiquini 's case isn't necessarily os or windowing manager specific. After he provided the additional details I started to wonder about the request url, http://localhost/Files. And then I also notice the original screen shot looked like it had an Apache favicon tab, so I tried experimenting with a local container running httpd and basic auth on a directory /files.

It looks like an error handling the response, which should be pretty simple to fix.

https://github.com/user-attachments/assets/bc087f79-09d5-4c69-95b3-20c535f4eb51

[jman-schief]

Adding my own +1 to this issue. Currently the http Basic has some UI issues that makes confusing the interaction with the website where Browserpass is triggered. In my case when I try to log into http://localhost:631 to manage the CUPS printer queue.

As suggested in this thread, adding credentials to browserpass for a number of localhost is in some cases complicated and confusing.

So, back to the first comment in this issue (in addition to #374 and #378 ): as of v3.11.0 the http Basic Auth seems to still have some rough edges. While a real fix is being designed, would it be possible to implement a flag/setting to just disable it? That would be a great temporary solution.

Thanks!

[max-baz]

Thanks for sharing your experience! Could you please elaborate on what exactly makes it complicated and confusing to add a pass entry for localhost? It would help to understand better exactly what we are trying to solve.

[allo-]

Seriously, the integration with HTML forms is neat and the overall UX of the extension is great and has useful shortcuts (one for OTP still missing, but the rest is very accessible) but the window here is the opposite as it gets into the way in particular on sites where one does not need/want it.

I think a quick fix for most people here would be to avoid opening the window when there are no passwords stored for HTTP authentication.

[max-baz]

I hear the frustration, and I totally acknowledge that changing a habit or a workflow requires both mental effort and time investment. Adding a pass entry feels unnecessary when your muscle memory is so quick to just type the basic auth credentials by hand. Adding a pass entry feels like a waste of time, when a different password manager has it saved already. Adding support for special cases is also extra effort and later maintenance burden, which is why we try to weigh in and consider how they fit in the UX of the extension aimed for people who want to use this extension as the password manager, and what exact scenarios they unlock.

Looking at the scenarios mentioned in this thread so far, I still believe adding a pass entry for a website that uses basic auth is worth the investment of doing it, pressing Enter in the popup window is a single-tap solution to login and is faster than typing it by hand, however short the password is. It promotes also using stronger and unique passwords, as you aren't required to type them manually anymore. Not using browserpass for the given login request is similarly a single <close-window> shortcut away (I thought Esc does it too, looks like not, I'd consider that a bug). I'm eager to hear from more people sharing in this thread specific examples of what they are trying to achieve and why and how the current solution stands in a way.

[jman-schief]

Ok, I understand the reasoning, thanks for the explaination. I have took the time to read this long thread more carefully. Allow me to rephrase my comment.

In this issue we have a broken usage report confirmed in this comment and I can reproduce that as well.

I have added an entry $PASSWORD_STORE_DIR/localhost/631.gpg to pass and it seems that it not picked up when I click on "Add Printer" ("Drucker hinzufügen"). IIUC this should work, right?

screenshot

I have to close the browserpass popup to unblock the browser http-basic window.

If relevant, I am using Debian testing (trixie) and Sway v1.10.1 (Wayland) without Xwayland

LMK if the conversation about this specific broken usecase should be taken in a new issue.

thanks

[allo-]

I agree with your sentiment about not wanting to add every setting one might want to have, but isn't this one just one single if before the window?

Let's explain my use-case in a bit more detail. I am still having mixed passwords in Firefox and in pass. I also have Firefox configured not to automatically insert them (but show a menu of stored accounts when an input is selected) as this was a security issue some time ago, but now still feels more comfortable not always to have everything prefilled.

That works very nicely together with browserpass. Firefox suggests something (but does not autofill it) for the field if there is something in Firefox' password store, otherwise it doesn't do anything. I then invoke browserpass with the keyboard shortcut and navigate with the keyboard through the menu. The UX is very good!

Now for http auth. I think it has in general not the best UX because it needs to be modal before loading the site and because the login is not cached between browser sessions (like cookie based logins). So in the end I would even prefer if Firefox would restore my HTTP auth sessions after opening the password safe, but at least I only need to hit enter one additional time for each site in a new session. With browserpass in between I need to close an additional window and still "dismiss" (i.e. confirm) the already annoying login dialog afterward.

The Firefox logins have two advantages that browserpass probably cannot implement due to the API restrictions: The password safe dialog is modal, which means I am sure to type into the right window. The http-auth login is tab-modal, which means that it uses the same focus as everything I do in the tab. The browserpass window is a completely different window, and interacting with it isn't clearly associated with a tab and closing with Alt-F4 has the association and risk of possibly closing too much.

Implementing Esc would already be a good improvement as it is way more a "dismiss dialog" key and usually doesn't do anything in important windows. If the browser window had focus, Esc would in the worst case stop the page from loading, but Alt-F4 might close the window with all tabs and possibly even terminate Firefox if no second window is open.

The bad thing about UX issues is, that it is hard to really pin down the problem and harder to suggest a good alternative. One instantly notices when something is annoying, but it's way harder to tell what's missing or what needs to be added to make things intuitive.

[max-baz]

In this issue we have a broken usage report confirmed in this https://github.com/browserpass/browserpass-extension/issues/377#issuecomment-2888566091 and I can reproduce that as well. LMK if the conversation about this specific broken usecase should be taken in a new issue.

@jman-schief this should be fixed in 3.11.0, if you still reproduce it in that version, please open a new issue, because this one is a bit too crowded now. Thanks!

I have added an entry $PASSWORD_STORE_DIR/localhost/631.gpg to pass and it seems that it not picked up when I click on "Add Printer" ("Drucker hinzufügen"). IIUC this should work, right?

Just to double check that it's not a typo, you should use : as port separator, exactly like in the browser url, so $PASSWORD_STORE_DIR/localhost:631.gpg. Or just localhost.gpg, but then it would match on other ports as well, which is less ideal. Finally you can just name it printer.gpg or any other name (even your current one) and on the first try the popup will not match it, but if you press Backspace, find the entry using search and login using it once, next time Browserpass will also propose this entry, regardless how it is named.

Let's explain my use-case in a bit more detail.

Thanks for the detailed explanation @allo-! I definitely understand that interplay is not ideal when you are trying to mix multiple password managers. It's true that we can't do a modal dialog like native FF can do, but I do believe we can aim to resolve the uncertainties that come from the fact that our window is not modal. For example, to be sure that you are entering password in the right window, browserpass shows you the domain of the page that requests a login. Is it your use-case that you have multiple window open with the same URL which both ask simultaneously a login and you need to login with different credentials, and it is therefore difficult to use Browserpass for this?

and closing with Alt-F4 has the association and risk of possibly closing too much.

Definitely agree, lets get the Esc keypress working in that window, a PR is always welcome or otherwise I'll try to do it at some point.

I agree with your sentiment about not wanting to add every setting one might want to have, but isn't this one just one single if before the window?

This is a step in the direction of "I want to use Browserpass for X but not for Y", where X or Y right now are "methods" of login, but in general could also be e.g. specific domains or other rules. Our main goal is to make the UX as good as possible with the assumption that you actually want to use Browserpass for everything 😁 Let me ask the opposite question, what would it take for you to move your credentials out of FF storage and into pass? I imagine in that case our focus will shift into some totally different direction, e.g. making it more clear which tab is asking for credentials, if that is ambiguous now.

[jman-schief]

Just to double check that it's not a typo, you should use : as port separator, exactly like in the browser url, so $PASSWORD_STORE_DIR/localhost:631.gpg

Understood && fixed. Thanks!