Document threat model of browser extension

[riedel]

Summary

I personally had a totally wrong misconception of the security provided through allowing the keepass-xc-browser addon. (see https://github.com/keepassxreboot/keepassxc/issues/4513#issuecomment-636322271 )

For me keepassxc also always provided reasonable protection while I the database was unlocked and I could watch what was going on against other applications with the same access rights. However, this seems to be dependent on user decisions (#4801)

As https://github.com/keepassxreboot/keepassxc/issues/4513#issuecomment-636345931 mentions it is really impossible to design "usable security" under the wrong or unknown threat model. I think it should become clear which part keepassxc takes responsibility for.

Examples

I did not think that any local application running under the same access rights as the browsers would be able to impersonate the browser and would profit from automatic key release.

Context

I was only tipped of when https://github.com/Frederick888/git-credential-keepassxc actually added more security which I unfairly deemed ineffective. It would be important to document a threat model, so extension developers can actually refer to it, when designing anything on top: https://github.com/Frederick888/git-credential-keepassxc/issues/5 .

[riedel]

To me a realistic threat would be a malware installed on my local account that

1. would check the chrome addons and check if the keepassx addon is installed
2. retrieve the id key once
3. probe until the database is unlocked
4. try to get common logins and hope that the user either sets those to "always remember" or simply thinks that some browser tab invoked the request

I actually can live with such a threat, if I know it, because the most common sites are demanding second factors by now and will be much more careful allowing permanent access to e.g. intranet signins. The data base is still secure against theft or malicous websites or web extensions or other users both on the network or even my computer.

An alternative threat that should be documented would be a key injection / screen recording malware.

The result of an analysis here could be that more delays should be introduced, so that at least someone watching the screen could interfere. Also the application should watch that it is always on top and is not obscured by other windows as a countermeasure (like windows elevation dialogs).

[phoerious]

This isn't fixable without MAC and code signatures. The browser binary would have to be signed and provide its code signature for authentication. Without signatures, any malware can impersonate any application. Checking the binary location does nothing, since the binary could simply install itself in that location.

[riedel]

Just to clarify: I was not asking to fix sth other than the documentation.

[Frederick888]

@phoerious I've been thinking whether it's possible to secure the key by (mis)using WebAuthn.

First of all, browser extensions run in secure contexts so the WebAuthn API should be available to KeePassXC Browser.

Then the authentication process of WebAuthn is basically a challenge-response mechanism. A client retrieves a challenge from its server, sends the challenge along with some info about the web page origin generated by browser to the authenticator, finally receives a signed challenge and a public key (and a counter, etc.).

The public key is what's important here. No matter whether it's a real key or generated on-the-fly via key wrapping, it should be unique to the origin info and user id, and it's supposed to be stored only in the authenticator and the server. So it means we can actually use the public key data as the key of a symmetric encryption algorithm to secure the NaCl keys.

From the users' perspective they basically just need to tap their key to 'log into' KeePassXC browser. But we should probably rewire test-associate to use an on-demand fashion. Supporting multiple keys might also need quite some efforts.

I haven't got time atm to prototype this but if the idea sounds valid, perhaps we can go through an RFC first to collect some opinions?

[riedel]

Could you give a short explaination why this issue was closed?

[droidmonkey]

This is a nice theoretical discussion, but unless you have a specific documentation change to contribute, I don't see any reason to go into this depth of discussion for the 99% of users.

[riedel]

Well security is always theoretical until there is damage done. I think I am the 1% user that cares about the security of my password manager and want to understand the implications of using it in one way or the other. However, security interestingly is handled in no part of the whole documentation.

To me it would be just good to know against what keepassxc is protecting me. I have learned that it is probably currently not really protecting me against any local attacker (same user priviledges). Still I do not really know because there is no documentation on it. I would volunteer to write such documentation if I really understood your take at security in the presence of a local attacker (same user priviledges).

It is also funny that the FAQ talks about the price of an audit. However, no auditor could ever do an audit without knowing what the software is trying to achieve in terms of security guarantees.

[droidmonkey]

No software running on the same computer that an attacker has access can guarantee you security. Full stop. Even fancy things like Intel SGX have been known faults and compromises. That isn't to say we don't care about your security or can provide information on how we provide security. That discussion is generally well above most users' head.

Here are our most obvious security features:

• Database fully encrypted at all times when at rest (in documentation)
• Database is protected using AES-256 encryption with the key protected with Argon2 KDF by default (in documentation)
• Memory is unreadable by non-admin users and programs not running as admin on local machine (in blog post)
• Communication between browser and KeePassXC is encrypted, however the key is stored with the browser (in this discussion)

Most of everything else is discussion around various features and how they are implemented to maintain the security of your data.

[riedel]

Ok you convinced me: I will simply try to do a pull request on the documentation to actually aggregate this information. I think a "normal" user should care and will not easily extract this information from different places. To me blog posts and closed issues do not seem a decent source of this.

To me it was important that the 4th aspect (memory) does not provide protection if the browser plugin is used in conjunction with "always allow" . IMHO the users need to know this if they have this security need (protect against a local malicious program).