Search for entries in the database through the browser extension

[slovdahl]

A feature I have come to really appreciate in the Kee plugin (previously known as KeeFox) is searching for entries in the KeePass database directly from the web browser. I manage a lot of logins to different web sites, and instead of having to bookmark the web sites in the browser and also having the same address in KeePass, I just use the Kee search as a bookmark search.

But now I'm getting tired of using the original .NET-based KeePass in Ubuntu, and I really like KeePassXC. So consequently, I'd like to suggest a similar search feature for the KeePassXC-browser extension.

Expected Behavior

The search bar could be shown when the extension icon is clicked. The search should be able to match on both title, user name and URL. Clicking on a search result would open the URL of it.

Possible Solution

This is what it looks like in the current Kee version:

[varjolintu]

This kind of behaviour would need modifications to KeePassXC side. Currently it's not possible to search matching entries without triggering a permission request. It's only allowed to search credentials per site.

[droidmonkey]

I do not endorse this behavior. It exposes the entire database to attacks with arbitrary search terms. The point of the browser extension is to only send credentials that match the current site URL.

[eprst]

Its up to the user to decide what level of security/convenience they want to have, so it must be configurable. I personally find this feature missing too, as I don't have correct URLs specified for a lot of entries, which makes browser extension almost useless.

[varjolintu]

The whole idea of the browser extension is to parse and match URL's in the entries.

If you wish to seach for all the entries without URL's being defined, you have to search for a different kind of browser extension that has direct access to your database.

[atroxix]

One practical use-case is when sites use external site for logins, e.g. making use of more and more common SSO. I.e. the original site URL is totally different from the login URL.

[varjolintu]

@atroxix Global Auto-Type already provides a solution for this kind of situation without giving the extension access to all credentials. You can trigger it also from the extension's context menu or keyboard shortcut.

[efokken-abb]

I do not endorse this behavior. It exposes the entire database to attacks with arbitrary search terms. The point of the browser extension is to only send credentials that match the current site URL.

I just happened across this thread and have the following question: What is the threat-model for this?

If I understand correctly, a malicious (hacked) browser can spoof any domain. In that case all entries for domains that appear in the browser history can be easily exfiltrated. Is there really an appreciable gain of security if the extension guards only against a malicious browser that can read out entries passed to the extension but not spoof domains?

Please understand me correctly: I am interested in understanding the issue, not so much in pressuring anyone into implementing a feature.

[varjolintu]

@efokken-abb The threat model for this feature is that we should not allow access to all credentials by default that could expose any passwords, which is currently the case. This can be disabled if the user wishes so. We also provide an API call to get all entries from the database, but only the UUID's, URL's, and titles are returned. Requesting a single credential (with password included) by the UUID will still required a manual confirmation, unless user has also disabled that default option.

And why not allow access to all credentials? The browser API is open to all possible clients (until this is merged). So in theory it's possible that when user has disabled all those access confirmations, some malicious application has retrieved the Identification Keys stored to the user's database, and tries to access the credentials using those. With all confirmation options disabled, the user would have no idea that the database has been even accessed, and all credentials are retrieved with a single call to the API. This is not something we want to happen.

The API request that allows returning all credentials (UUID & URL & Title) could be used with the browser extension to search all credentials from the database, but that feature has not been implemented yet. And it would still require an extra confirmation by default from KeePassXC side.

[efokken-abb]

Ok, that gives me a broader perspective. What I get from this is, that basically using the browser plugin at all is a security problem, until your PR is merged. If I understand you correctly, the mitigation provided by only returning passwords if the correct URL is asked for, can be circumvented by any app that accesses the API by just trying all URLs, which are interesting to the attacker. If that is the case, only password fields that don't have an URL or those with very obscure URLs are safe. Is that so?

[varjolintu]

@efokken-abb All I'm saying it can be a security problem in theory if user disables some settings that are meant to keep the database and credentials safe. No, the requests cannot be circumvented by just knowing the URL. To even make a successful request to the database it needs to be connected to the client with a separate Identification Key (plus the client name that was given at the connection phase). If those are not known, your database cannot be accessed via the browser API.

[efokken-abb]

Ok, so that means, it is not (easily) possible, that any malicious executable on the system can access the browser API, even before your PR. If it could, credentials could be accessed if their URLs can be guessed.

On the other hand, the browser API doesn't allow random searches, apparently for additional security. In case you are still willing to entertain my curiosity, I would like to know, what additional security that is (It's your spare time, don't feel pressured to answer me!). As far, as I understand the additional security is given by the fact that a malicious browser (or otherwise hacked browser plugin) can only exfiltrate credentials with an URL and that URL must be guessed. I don't mean to belittle that additional security, for example credit card pins probably don't have an URL field and therefore are protected.

Is there additional security gained by the prevention of random searches from the browser plugin?

[varjolintu]

@efokken-abb What do you mean by "random search" here?

[efokken-abb]

I mean searches for strings in arbitrary fields of a database entry.

[varjolintu]

@efokken-abb It's (the URL) just the minimal amount of data needed to match a credential to a web site.