Associate browsers with KeePass globally, not with databases

[elieux]

Is it possible to completely move the keys to global KeePass settings and treat inactive databases as equal with the active one? I noticed the association procedure is not very helping (at least it wasn't when I used it) when one needs to associate a browser with multiple databases.

I was going to propose moving the key from the special "KeePassHttp Settings" entry to database settings (which would also need a custom UI - presumably a new tab in Database Settings), but then I realized that the association is not really a property of a database; I want to associate my browser with my KeePass (specifically with the KeePassHttp server), have it automatically use all my databases and then, only if needed, I may choose some databases to be ignored by the plugin (which could, but not necessarily, be a property of each database).

Similar work has been done in the KeeFox plugin.

I brought up this request in #47, @pfn then argumented that this wouldn't be secure and @lspcity asked me to create a new issue for this.

I'm still curious: Why is it not secure?

[pfn]

The primary reason this would not be secure is where would the storage of the association key be kept? In a keepass database, it is encrypted with your password. If it is stored anywhere else that is not password protected; anyone with access to this configuration file can extract and decode (since there is no user-entered password, it is only obfuscated and not encrypted safely) the access key.

Once an attacker has this access key, your database is no longer safe. I suppose the same could be argued of storing the access key in chrome and firefox's profile, but both of those environments do offer some modicum of safety (e.g. firefox allows setting a master password, which will encrypt the access key securely). Chrome doesn't have this protection, yet (although, if I were really paranoid and there was a demand for it, I could add a password-based unlocker for the access key to chromeipass)

tl;dr: the primary reason why it is insecure is that there is no real safe place to store a global access key. on a mac, one could store it in the keychain, there's no good analog for windows.

[elieux]

Once an attacker has this access key, your database is no longer safe.

I don't follow. Is it because KeePassHttp uses this as a shared secret for authentication? (I assume that--if the key is one of a pair generated for asymmetric crypto--the worst an attacker could do with that key is pretend to be KeePass and provide bad passwords to the browser.)

[pfn]

Vice versa, the key grants access to keepass

Sent from my phone On Mar 23, 2013 4:17 PM, "elieux" notifications@github.com wrote:

Once an attacker has this access key, your database is no longer safe.

I don't follow. Is it because KeePassHttp uses this as a shared secret for authentication? (I assume that--if the key is one of a pair generated for asymmetric crypto--the worst an attacker could do with that key is pretend to be KeePass and provide bad passwords to the browser.)

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/88#issuecomment-15347495 .

[elieux]

I may have phrased the question badly. Is there one key (shared secret), or two keys (asymmetric key pair)?

If it's the latter, then there should be no big harm in disclosing KeePass's key. If I get the key which KeePass uses to authenticate, I can impersonate it and see what sites the browser visits and provide bad passwords. To read the real passwords, I'd need the browser key.

If it's the former, I understand that the key needs to be protected, but then why not switch to the other, presumably safer, method?

[pfn]

It's a symmetric system, client certificate management is a pain to make user friendly.

Sent from my phone On Mar 23, 2013 6:35 PM, "elieux" notifications@github.com wrote:

I may have phrased the question badly. Is there one key (shared secret), or two keys (asymmetric key pair)?

If it's the latter, then there should be no big harm in disclosing KeePass's key. If I get the key which KeePass uses to authenticate, I can impersonate it and see what sites the browser visits and provide bad passwords. To read the real passwords, I'd need the browser key.

If it's the former, I understand that the key needs to be protected, but then why not switch to the other, presumably safer, method?

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/88#issuecomment-15349611 .

[elieux]

I'm wondering, what's the difference to the user?

The tricky thing about public asymmetric crypto (for instance HTTPS) is how to know whether to trust the server. PKI and trusted root CA's are commonly used to solve this (to some extent), but you don't have to use public infrastructure -- you already have the association process, where you can establish a solid level of trust.

Regarding the technical side of the matter, I'm assuming you have to implement the algorithms in JavaScript (because IIRC there's no API or built-in support for symmetric crypto in Chrome/WebKit/V8). If it's the case, then there should be no problem exchanging the algorithms for asymmetric ones. (As opposed to using HTTPS. Then the browser would probably complain about untrusted certificates.)

(In case my questions seem offensive, please bear with me, I'm just trying to understand.)

[pfn]

There isn't a good, purely-javascript asymmetric crypto library.

On Sat, Mar 23, 2013 at 7:04 PM, elieux notifications@github.com wrote:

I'm wondering, what's the difference to the user?

The tricky thing about public asymmetric crypto (for instance HTTPS) is how to know whether to trust the server. PKI and trusted root CA's are commonly used to solve this (to some extent), but you don't have to use public infrastructure -- you already have the association process, where you can establish a solid level of trust.

Regarding the technical side of the matter, I'm assuming you have to implement the algorithms in JavaScript (because IIRC there's no API or built-in support for symmetric crypto in Chrome/WebKit/V8). If it's the case, then there should be no problem exchanging the algorithms for asymmetric ones. (As opposed to using HTTPS. Then the browser would probably complain about untrusted certificates.)

(In case my questions seem offensive, please bear with me, I'm just trying to understand.)

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/88#issuecomment-15349922 .

[elieux]

So if you find a library that satisfies your criteria, you'll be willing to go for asymmetric crypto and then maybe put the key in global settings?

[pfn]

Possibly, yes. But, there's at least one more consideration: an attacker may be able alter the keepass config to put their own key there. No knowledge of the database password, but now have access to the database once unlocked.

On Sun, Mar 24, 2013 at 10:03 AM, elieux notifications@github.com wrote:

So if you find a library that satisfies your criteria, you'll be willing to go for asymmetric crypto and then maybe put the key in global settings?

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/88#issuecomment-15362711 .

[elieux]

Oh. Interesting. I'll think about it.

In the meantime, I created a separate issue for replacing the crypto algorithms.

[elieux]

So, I didn't actually think much about it, but I referred to the author of KeePassRPC and KeeFox and he came up a good answer IMO.

Essentialy, if it's possible for an attacker to edit/put files on your computer, they can probably provide you with modified versions KeePass/browser/addon/other extract the database key or passwords themselves anyway.

Sources: an overview of the security of communication between KeePassRPC and its clients, my KeeFox security question on Zoho

[pfn]

Yes, that's true but I'd rather not make it easier.

Sent from my phone On Apr 7, 2013 11:34 PM, "elieux" notifications@github.com wrote:

So, I didn't actually think much about it, but I referred to the author of KeePassRPC and KeeFox and he came up a good answer IMO.

Essentialy, if it's possible for an attacker to edit/put files on your computer, they can probably provide you with modified versions KeePass/browser/addon/other extract the database key or passwords themselves anyway.

Sources: an overview of the security of communication between KeePassRPC and its clientshttp://keefox.org/2010/12/11/keepassrpc-security-and-authentication/, my KeeFox security question on Zohohttps://discussions.zoho.com/keefox/topic/is-keefox-secure

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/88#issuecomment-16034736 .

[rugk]

Current status as of 2017: KeePassHttp is not secure anyways.

I think you can close this issue. The plan is to move to Native Messaging (see KeePassXC) as a more secure alternative.

[SjorsH]

Wouldn't it be possible to specify which database the browser association is stored (and store this globaly)?