search

kee-org / keepassrpc

The KeePassRPC plugin that needs to be installed inside KeePass in order for Kee to be able to connect your browser to your passwords
GNU General Public License v2.0
635 stars 35 forks source link

KeePassRPC port issue on terminal servers #104

Open wschlich opened 4 years ago

wschlich commented 4 years ago

Hi,

when using KeePass with KeePassRPC on a terminal server with multiple users, it's quite a hassle to change the KeePassRPC port for every user in:

By default (using KeePassRPC Port 12546), user A (with KeePass opened) could get quickly irritated and annoyed by "authorise a new connection" popups triggered repeatedly by user B (with browser and Kee Plugin opened).

Normally, I'd suggest choosing a random port from a port range (for example 29170-29998) on the first KeePassRPC startup, but I believe there's no easy way for the Kee browser plugin to get to know this user specific port automatically, right?

Cheers, Wolfram

thespooler commented 4 years ago

This is indeed a problem and not only for terminal servers. Fast user switching exhibits the same behaviour. For example, on a computer with multiple users. When the first user logs-in, start FFox and KP (thus KPRPC), then switches to another account without closing KP, FireFox and signing-out, on the second account, FFox KPRPC will keep trying to establish a connection with the KP in the first session, prompting user action in the first session. Conversely, if KP is closed in the 1st session, but FFox is still loaded, KP in the second session will keep prompting for access, never succeeding. Perhaps something like Native messaging and per-user Native_manifests?

kohtala commented 3 years ago

Native messaging looks nice. It requires some more setup and preferably an installer, which would not be so bad anyway, because the KeePass plugin install manually is anyway rather difficult.

If I understood right, it requires an executable the browser will launch and communicate with through stdin/stdout. This executable needs to find the per session KeePass.

On Windows KeePassRPC plugin could expose endpoint named after the Logon SID. Unfortunately I do not think the browser plugin has direct access to Logon SID, so the native client is needed. The endpoint could be via Named Pipe (or RPC). The KeePassRPC should protect the named pipe using Logon SID in ACL and maybe also deny access to NT AUTHORITY\NETWORK to further enforce no remote access. I don't think any of this reduces the need for each end to authenticate the other end of the link.

luckyrat commented 1 year ago

As already mentioned, I don't think there is any way to avoid these limitations of TCP port communications so a switch to using native messaging may be the only possible way forward (even then, I don't know enough about terminal servers to be certain it would solve all the configuration challenges).

A switch to using native messaging is already being tracked in the browser addon repo - https://github.com/kee-org/browser-addon/issues/23 . Although changes to the KeePassRPC plugin are likely required, I think it will be the needs of the browser extension that will drive the development and determine what we need to do here. I'll keep this issue open as a reminder to consider the information you've all supplied when I next investigate the feasibility of using native messaging in Kee but note that in future, using the community forum will likely result in a faster response (I've just added a GitHub issue template to make that clearer for people arriving at this repo from routes that don't already mention that).