keepassxreboot / keepassxc-browser

KeePassXC Browser Extension
GNU General Public License v3.0
1.77k stars 188 forks source link

One domain in multiple browser profiles #353

Open morfikov opened 5 years ago

morfikov commented 5 years ago

I'm using several different profiles of the Firefox browser. Each profile has slightly different configuration -- I use the profiles to visit different sets of websites. Each profile has its own google account. I added all of these accounts to KeePassXC database (separate entries), and they all aim to https://accounts.google.com/ . I installed the KeePassXC-Browser extension in each browser profile and connected it to the KeePassXC database. When I visit https://accounts.google.com/ in any browser profile, the KeePassXC extension wants to access all of the entries that matches the URL. What I want to achieve is to separate those logins, so each browser profile could access only the credentials that is supposed to and at the same time ignore the rest of them. Is that possible?

KeePassXC - Version 2.3.4
Revision: 6fe821c

Libraries:
- Qt 5.11.2
- libgcrypt 1.8.4

Operating system: Debian GNU/Linux buster/sid
CPU architecture: x86_64
Kernel: linux 4.18.0-2-amd64

Enabled extensions:
- Auto-Type
- Browser Integration
- Legacy Browser Integration (KeePassHTTP)
- SSH Agent
- YubiKey
varjolintu commented 5 years ago

No. The extension has no information about your profile. The entries are matched only by the URL.

morfikov commented 5 years ago

But KeePassXC knows which browser profiles (or browsers) are connected to the database -- they have different names and public keys, which have to be confirmed in the app. So technically KeePassXC could check whether this public key/name has access to the specific credentials, right?

Also, what is this Realm in {"Allow":["accounts.google.com"],"Deny":[],"Realm":""} ?

varjolintu commented 5 years ago

KeePassXC only knows the connected browsers, and they all have the same Allow/Deny permissions. Those are not handled separately based on the connected ID.

Actually, there's no documentation about Realm in the KeePass site. An old forum post indicates it has something to do with filling the username again. Still, I think it's not really used at all.

morfikov commented 5 years ago

So the only option is to use a separate database for each browser profile?

What about implementing such feature? It would be really nice to have this kind of browser-domain-credentials validation.

varjolintu commented 5 years ago

This would also mean that when losing the key/connection with the browser, every entry has to be allowed/denied again, one by one.

Now the Allow/Deny uses the URL for the value. If those values are replaced with the connection ID, that would work without any big changes to the codebase.

varjolintu commented 5 years ago

@droidmonkey @phoerious Do you have any suggestions concerning this? Currently the entry Allow/Deny permissions are saved with the URL or submit URL (I guess this is because previously titles were also matched, so the entry would be allowed/denied even if the entry URL differs). It would probably make more sense to save these Allow/Deny lists with the connection ID instead. This would allow separate permissions per connected browser or a browser profile. Now every browser connected to the database is automatically allowed or denied based on the current setting of each entry.

Now the plugin data looks like this: {"Allow": ["github.com"],"Deny":[],"Realm":""}

After the change it would look like (chrome and firefox as connected ID's): {"Allow": ["chrome"],"Deny":["firefox"],"Realm":""}

EDIT: This could also make things easier in the future when entries can have multiple URL's.

droidmonkey commented 5 years ago

This is a very very specific use case that, imo, should not be applied by default. The vast majority of users want the same behavior across browsers, OS's, and between profiles. If anything this would be opt-in.

For this particular case, I would recommend that OP just add the profile name to the title of each GitHub entry. That will allow them to differentiate and select the correct one for each profile even though they are all returned.

The less convienent workaround is to create a different database for each profile and only connect that profiles extension to its respective database. You could even setup AutoOpen so you only have to unlock one database and the others will unlock automatically.

morfikov commented 5 years ago

This is a very very specific use case that, imo, should not be applied by default. The vast majority of users want the same behavior across browsers, OS's, and between profiles.

I want that too because it's useful, and it shouldn't be changed. But some entries are more valuable than others, for instance the google account vs some gaming_website account. I don't mind all the browser profiles (or browsers) to have access to the gaming_website credentials by default, but the access of the credentials of the google account should be granted with caution.

I'm rather thinking of some option that could be added to an entry, let's name it Browser Public Keys. If this option was set and some public keys were provided (could be one or more), this entry (and only it) would get an extra access check based on the public keys. If the public key in the entry matches with the browser profile's public key, which tries to access the entry, the access would be granted. At least I see it in this way. :)

0xC4N1 commented 5 years ago

@droidmonkey wrote: The less convienent workaround is to create a different database for each profile and only connect that profiles extension to its respective database. You could even setup AutoOpen so you only have to unlock one database and the others will unlock automatically.

I want to give scripts like those mentioned in #359 access to certain credentials and have other keys protected from those scripts. This workaround doesn't seem to be a solution for me because it requires the user to unlock the database and select the correct database with script access. It seems like the keepassxc-protocol can only give me the currently selected database.

JohnLGalt commented 1 year ago

I realize that this is one hell of a Zombification for a topic, but it's still open, so....

Has this been considered again at all? I have 3 regular (personal) Google accounts but also 4 Google Workspace accounts. I don't fancy keeping 7 different databases handy and ready to go, not after the proliferation that has occurred amongst all the different sites using different accounts. I have, however, created individual browser profiles for each account (for the sake of isolation), and I assumed that I would be able to simply deselect all but the relevant login for, say, GMail, in the the browser addon in a given profile, but in fact all my profiles now only allow that one account.

I'd rather have each entry allowed only in specific profiles in some cases, and browser wide (even system wide) in other cases.

If it was handled at the browser addon level itself, I'd be perfectly fine with that, each profile having its own isolated and dedicated browser addon (which is what I thought profiles were supposed to do in the first place).

Or does it work this way and I'm simply missing something?