Separate lock for browser plugin

[Vilx2]

Summary

This is the second incarnation of my earlier proposal. I've looked at some other proposals which are still active to get an idea of what would be acceptable and what not:

• Unlock database only for the browser extension's use
• Add QuickUnlock Feature
• Feature Request: Windows Hello support

What I propose is basically the same as QuickUnlock, but with a separate password solely for the browser plugin.

Desired Behavior

After unlocking the database with the Master Password once, the "BrowserQuickUnlock" feature gets activated the same way as QuickUnlock. The password (henceforth: Browser Password) for this is taken from the database where a special configuration record holds it. It does not need to be related to the Master Password at all.

When the browser plugin needs website credentials it first tries to get it the default way (without password) but receives an error that the DB is locked with a BrowserQuickUnlock possibility. The browser plugin then prompts the user for the Browser Password. If supplied correctly, the DB is unlocked, credentials are retrieved, and then the DB is locked again. If supplied incorrectly (configurable to X attempts), the BrowserQuickUnlock is locked needs to be unlocked with a Master Password again.

The BrowserQuickUnlock would only return one username/password per request. For the next request it would require the Browser Password again. Since the browser is considered an insecure land (from the viewpoint of KeePassXC at least) there would also be a rate limit to prevent an automated probing of the DB. More than, say, 1 request per second (configurable) and the feature gets disabled entirely. You need to re-enter KeePassXC with the Master Password, and re-enable it manually. Re-enabling would also show you a big red prompt that the rate limit was exceeded and that your browser is possibly compromised.

Context

I desire this feature because, like in "Unlock database only for the browser extension's use" I'd like to enter some sort of password before having my form fields auto-filled, but I don't want the focus to go away from the main browser window. My hope is that the feature in this form will be acceptable from a security standpoint - it's no less secure than QuickUnlock, and maybe even more so, because the Browser Password only allows to access website credentials, not the entire database.

[droidmonkey]

Why not just use the same mechanism as the QuickUnlock itself (ie, just use QuickUnlock)? I don't see any value in having two separate "quick unlock" passwords. This will likely just confuse users who have to setup quick unlock in two different locations.

[varjolintu]

If you want some confirmation before auto-filling, one thing you could try is to remove all site-specific data from your entries (Browser Integration settings in 2.3.4, Database settings in 2.4.0). Then you will get a confirmation dialog every time the extension is trying to access your credentials. Using the Allow/Deny without remembering the option will keep showing you the confirmation dialog.

For single entries, you can delete the Allow/Deny access from entry's settings (Edit Entry -> Advanced, then delete the KeePassXC-Browser attribute. With 2.40 this is found from Edit Entry -> Properties's Plugin Data).

[Vilx2]

Why not just use the same mechanism as the QuickUnlock itself (ie, just use QuickUnlock)?

Because

I don't want the focus to go away from the main browser window.

This is about flow of interaction. Manually switching between windows multiple times is pretty annoying.

Alternatively I would be OK if the browser plugin would restore (if minimized) and focus the KeePassXC window for entering the password; and afterwards KeePassXC would re-minimize and re-focus the browser window - but that's even more work and I'm not sure if a Chrome plugin would even be able to do that. At least on the Windows platform (which I'm most familiar with) the browser plugin would require some pretty low-level access to the OS API. And the whole thing becomes pretty fragile and there are many edge cases to handle (what if the user switches away from the KeePassXC window? What if the user closes KeePassXC without entering the password? What if the user closes the browser tab? etc.)

Therefore I propose a mechanism where the browser plugin would display a password prompt instead, not needing the whole dance with the input focus. It's a lot simpler both for the user and KeePassXC developers.

Then you will get a confirmation dialog every time the extension is trying to access your credentials.

I don't want just a Yes/No confirmation dialog. I want a password prompt. I want there to be some authentication before KeePassXC returns the credentials to the browser. The reason is that I don't want people who gain temporary physical access to my computer to be also able to log in to all the websites.

[varjolintu]

Auto-Type already uses some lower level API's on all platforms, and the browser integration got some improvements to the macOS side for the 2.4.0 release. Linux already works pretty decently, but Windows definitely has some drawbacks. (Also worth of remembering: https://wiki.qt.io/Technical_FAQ#QWidget_::activateWindow.28.29_-_behavior_under_windows)

After reading your suggestions, I would suggest you to test Auto-Type because it would deliver exactly the workflow you are after.

[droidmonkey]

I could support doing QuickUnlock from the browser extension.

[Vilx2]

I'll try the autotype, but from what I glanced before, it was no picnic either. If I remember correctly, it relied on the window title, which meant that to make it work semi-reliably you also needed to add a browser plugin that changed the window title to the URL of the page. But I'll give it a shot.

[fabianski7]

I'll try the autotype, but from what I glanced before, it was no picnic either. If I remember correctly, it relied on the window title, which meant that to make it work semi-reliably you also needed to add a browser plugin that changed the window title to the URL of the page. But I'll give it a shot.

which plugin is that @Vilx2?

[Vilx2]

which plugin is that @Vilx2?

Sorry, I don't remember. :(

At this point I've given up and just manually unlock the database and copy/paste the password every time I need it. It's awkward, but I don't need to do it that often, so... it's ok-ish.

[fabianski7]

which plugin is that @Vilx2?

Sorry, I don't remember. :(

At this point I've given up and just manually unlock the database and copy/paste the password every time I need it. It's awkward, but I don't need to do it that often, so... it's ok-ish.

Why don't you use the browser extension? It's a bit buggy but it works.
I'm using auto-type only on sites I access more often. It took a while to manually set the windows name but I believe it's more secure than the browser extension...

[Vilx2]

Because using it is more of a hassle than not. Whenever I need a password I still need to manually switch to and unlock KeePass. After I've done that it's simpler for me to just click the relevant entry and Ctrl-C/Ctrl-V the password rather than go back to the browser and fiddle with the plugin. And I don't want to keep KeePass unlocked all the time because that kinda defeats the purpose of being secure.

[droidmonkey]

This will be covered by implementing Quick Unlock.