Is there a way to disable the HTTP Basic Auth prompt from Kee? We have a corporate system that will pop up the dialog to select a password for basic auth response, but if you click cancel it will then pop up again for the next asset on the page. If you don’t immediately login with valid credentials you can end up with hundreds of open dialogs from Kee.
It’s not possible to disable it I’m afraid.
Depending on your specific needs, you might find that automatically submitting the credentials is helpful - set the option “When Kee finds only one matching network login (e.g. HTTP Auth), automatically login” and make sure that the URL match configuration for each relevant entry is strict enough to limit the list of options presented from KeePass to Kee.
Yeah, configuring automatic submissions isn’t going to work because if the credentials are wrong or it chooses the wrong entry then it is going to make hundreds of failed login attempts.
Can we have a feature request to be able to control the HTTP Basic Auth prompts and submissions better? Maybe an option to enable/disable, and choose how many times the prompt is shown?
I have been trying to think of a way to improve this situation somehow but haven’t come up with a perfect solution yet. Here’s where I’ve got to in case it leads to a concrete feature request now, or just jogs the memory in future years when technology has changed to make some more ideas feasible.
The only option I see currently would be an option to disable the network authentication support either entirely or on a per-site basis. This would include proxy auth (and NTLM auth if browsers ever get around to allowing extensions to control this).
So the question is whether this would actually help in your specific scenario @snovak and from there whether anyone in the community can foresee a problem from this approach?
I can’t see a downside of it at the moment (beyond it being a potentially niche bit of code that’s another thing that can go wrong and has to be developed in the first place… but that can always be countered by someone contributing the code so on its own is not enough for me to be against the idea of this feature).
My reasoning for the above follows…
We already block the network request until the user has had time to select the appropriate credentials.
In years gone by this would cover 99.99% of websites since the initial load of the web page can’t happen until the credentials have been entered. Since subsequent assets on the page won’t even be known about until these credentials have been entered successfully, there’s no chance of multiple prompts being displayed.
There are some increasing exceptions to this behaviour though.
For a start, I have seen that the use of ServiceWorkers allows that initial page load to be bypassed in some cases, loading the initial page contents from the offline cache and therefore causing the browser to trigger multiple new requests for assets that may also be behind a Basic Auth prompt.
I also suspect that websites which utilise iframes, or perhaps dynamically inject images protected by Basic Auth, will be able to trigger multiple requests that can’t have their credentials automatically satisfied by credentials the browser already knows about.
In all of those cases, web browsers have yet to settle on an approach that works consistently, even within a single browser, let alone when comparing Firefox and Chrome.
There is still ongoing discussion regarding how the browsers themselves should handle the concept of a non-blocking Basic Auth request (as evidenced by the default prompt still being tab-modal after so many years). I wouldn’t like to predict whether this is something that browser vendors will change eventually or whether their focus will continue to shift away from Basic Auth and towards modern Auth solutions that don’t suffer from a lot of the inherent limitations of the Basic Auth protocol.
Since we can’t know anything about the entries that might match a Basic Auth request until after we have had to respond to the browser to indicate our intention to block or not, this precludes the possibility of controlling Basic Auth based upon which entries match.
While I suspect that we could track the number of times a prompt is shown, I’m not sure if there is a feasible action we can take with that information.
For example, should a new request for basic auth that goes beyond this limit be rejected (i.e. the user will have to refresh/retry to have another chance), deferred to the blocking tab-modal browser auth dialog (probably preventing any use of Kee for existing Network Auth requests in that tab), queued up for later prompting or automatically resolved with the same entry that was selected for other requests for the same file/directory/hostname/domain?
I just don’t see that it’s feasible to develop an algorithm that will always be able to come up with the correct answer to those questions for all users and websites. The consequences of getting it wrong will mostly be limited to user annoyance but I’m not convinced that we’ll be able to 100% reason away the possibility of leaking a password to the wrong network request so I am naturally wary of giving this idea further investigation.
I think having a white/black list would be perfect. For instance, you could add internal company domains that you might want to allow HTTP Basic for, but deny it for other sites. Also if one particular site was causing problems, you could just add it to the denied list. It would be even better if the list could take subnets so you could block private IPs, or foreign netblocks.
If nothing else, there should be an option to deny filling out or submitting information that is not HTTPS. I don’t want a computer on the local network to pretend to be a domain or site, send up a Basic HTTP Auth request and have Kee send the credentials. I suppose this could be a separate issue / request though.
Thanks for the feedback.
It would have to use the same per-site management system that is already in place really so there’s not much chance of IP subnet based rules I’m afraid. In any case, I’m not sure if that’s exactly what you’re imagining - the information the browser gives us is about the displayed URL in the address bar so we have no way of making decisions based upon what IP address that resolves to. It almost sounds as if that idea is stretching into a general network blocking feature rather than something specific to how we handle Basic Auth. Or is there something I’m missing about how Basic Auth is being abused in a particular way by some malicious users that are identifiable by their source IP address/subnet? I’ve not heard of anything like that which is specific to Basic Auth but am happy to be educated.
Yeah I have recently been thinking a bit about adjusting behaviour based upon HTTPS or HTTP. I think HTTPS is almost prevalent enough that there are some potential benefits for changing things like auto-fill behaviour based on protocol used. However, that’s definitely a separate issue, and something I’ll have to flesh out and present in a new topic for community feedback before making changes. I’m not sure whether HTTP Auth needs any different treatment to that of a normal form in this regard but maybe we’ll think of something in future.
@luckyrat - You’re totally right that changing behavior based on the connection type should be a different request. I’ll start a new topic for that one.
Disable Basic Auth feature request…
Maybe rather than disabling basic auth prompting for the entire extension, it would be better to be able to disable it for specific sites or conditions.
Kee already has a section called “Finding forms” that has a whitelist and blacklist section to allow/deny finding and completing of forms based on the form names and field names. It seems like it would be good to have a similar option based on URL / domains. I know that LastPass has an option for adding “Never URLs” that are URLs that are ignored by the application so that it does not try and fill forms, auto login, or store information.
If Kee were to look up the IP address of the hostname in the URI, then it could also allow/deny based on the IP address for the host as well. It would be great to be able to block Basic Auth and Auto-Fill if the IP address was say, an RFC1918 (non-public) IP for instance.