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 #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.

[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.