Idea for a better browser experience

[Vilx2]

I tried contacting people on the IRC channels to discuss these ideas, but the channels were silent, so I'll post it here in order to get some feedback on it. I can also contribute code, if these ideas are appreciated.

So, basically, I finally gathered the courage to start using a password manager. After a bit of exploration I found KeePass to be highly recommended and decided to use that. I liked it, but the browser integration felt a bit underwhelming, so I explored more and found KeePassXC. Unfortunately, the browser integration isn't much different. Or maybe I've just not yet understood the KeePass mindset, in which case I'd like to hear where I'm wrong or why this isn't a problem.

My main issue is that I don't want to keep my database unlocked at all times. Password managers are there to be secure, but it kinda defeats the purpose if anyone who can walk by my computer can also quickly take a glance at all my passwords. The way I imagine a good workflow is that when I need KeePass (like when I try to log in somewhere or create a new account), I need to enter my master password, then I do what I need to, and then the DB becomes locked again.

The browser integrations do support this of sorts - but doing this brings the KeePass(XC) window to the foreground and unfocuses the browser. And after that I manually need to switch back to the browser window to continue doing what I was doing. Locking the DB needs to be done either manually or it's on a timeout. All in all - a lot more hassle than it should be.

So my first idea - the protocol that KeePassXC uses to communicate with the browser plugin could include a way to unlock the database from the browser plugin. With this the browser plugin could show little password prompt without breaking away from the browser. And after the operation is complete, the browser plugin could also immediately lock the database. KeePass would stay in the background at all times and just act as a true server.

And this actually brings me to my second idea - a KeePass server. This is obviously a lot bigger, yet much of the needed functionality seems to be already there - it just needs to be brought together in the right way.

Currently KeePass(XC) relies on nothing more than file sharing. For multiple users (or multiple devices of a single user - like me) to use the same password database, there needs to be some sort of external file sharing mechanism. The file could be stored on an NFS/Samba share; it could be synchronized via Google Drive or some other cloud service; etc. This is simple, but it also requires all the devices to have KeePass(XC) and the sharing mechanism installed. It's a bit of a hassle to set up, to be honest, and I can imagine scenarios where it could be difficult if not impossible.

Since the browser plugin already uses a remote protocol for connecting to KeePassXC, why not extend this to reach over the network? I understand that the KeePassHttp protocol is considered insecure (though I've not read the details) - OK. Why not create a new, secure protocol then? Authentication would happen with the same master password. Bonus points for basing it on HTTP so that it passes easily through firewalls and proxy servers.

This way you only need to install KeePassXC on a single machine and then you can securely access your passwords from all your devices, and synchronization becomes a lot easier as well. There would also be no need for the keepassxc-proxy.

In the future this principle also allows for other interesting developments. Like, you could have shared databases that each user opens with their own password; databases with different privilege levels depending on the user who opened it; remote database creation/deletion; etc.

I'm interested in hearing your thoughts.

[varjolintu]

Just a quick answer concerning keepassxc-proxy; It's still needed for native messaging.

I'll reply more later.

[phoerious]

The protocol does support unlocking, but it has to be done in KeePassXC, since we do not want to pipe the master password through a third-party application and possibly allow websites access to it if they manage to break the browser's sandbox. We are working on making unlocking a bit easier, but it will be KeePassXC that does it. Focus should switch back to your browser after that.

We also don't "just" do file sharing. We communicate via sockets which is a secure IPC method preventing third application from listening. We had an HTTP interface before, but deprecated it as our new integration is more secure.

[Vilx2]

The protocol does support unlocking, but it has to be done in KeePassXC, since we do not want to pipe the master password through a third-party application and possibly allow websites access to it if they manage to break the browser's sandbox.

I was afraid there would be some reason like that. Pity, it's exactly what I wanted - to give a 3rd party application the ability to unlock the database by supplying the master password. But I also understand your reasons.

We also don't "just" do file sharing. We communicate via sockets which is a secure IPC method preventing third application from listening.

No, no, you misunderstand me. Sockets/named pipes are IPC methods which are indeed secure, but only allow communication between processes on the same machine. I was thinking about networked communication, where multiple machines could connect to the same database via TCP/IP.

But the reason for this desire was to avoid maintaining the DB locally, and that can't be done if a 3rd party app cannot unlock it remotely.

OK, thank you, back to the drawing board for me. :) If there are no more replies soon, I'll close this issue.

[Vilx2]

The protocol does support unlocking, but it has to be done in KeePassXC, since we do not want to pipe the master password through a third-party application and possibly allow websites access to it if they manage to break the browser's sandbox.

I was afraid there would be some reason like that. Pity, it's exactly what I wanted - to give a 3rd party application the ability to unlock the database by supplying the master password. But I also understand your reasons.

On the other hand... It wouldn't really be less secure than the browser's own built-in password manager, would it? And the communication protocol can also be made safe enough to pass the master password through without worrying about eavesdroppers. That leaves it as a matter of trust. Perhaps this feature (remote unlocking) could be added as an optional off-by-default setting?

[droidmonkey]

The issue with your suggestion of unlocking the database through the extension is that you are giving up critical information about the source of the passwords to the browser. Even though we trust our extension, it runs in your browser with other extensions and unknown vulnerabilities. The whole point of KeePass and KeePassXC is that it is an offline, highly secure password manager. There are plenty of other managers that fit your requirements but they trade security with convenience in almost all cases.

For the client/server idea you had, I recommend you look into KeeWeb. This might better fit your vision. We are not in the business of implementing a network-based sharing infrastructure. At best, my recommendation is to use a cloud file service to store your password database in that syncs between your devices. This is what I do and it works amazingly well.

[Vilx2]

OK, I understand. Thank you! :)