Password for export and change password

[xantoniorx]

I am disappointed because when exporting the database no password is required. And when I want to change the master password no password is required.

For me it is a bad lack of security because if an attacker who has managed to have access to the PC locally or remotely he can change the password or export the entire database in clear text in a second without any kind of protection. It's rare but it can happen and if it happens game over!

All password managers require the master password to export and change the master password. I don't understand why KeePass XC doesn't! That's why I don't use KeePass XC because it's too insecure for it.

I hope you will include this important protection becouse if this problem is not solved it remains a totally useless application to contain passwords.

[oskar2517]

If an attacker has access to your unencrypted database, you have lost anyway. How is that even supposed to work? A website can ask you to confirm a password change by forcing you to enter your current password first but that only works because the user cannot control the backend directly. That's not the case here. The UI is running on the same computer that has been compromised.

There is some fundamental misunderstanding of how local programs work at display here.

[droidmonkey]

Who submitted this? https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-35866

[phoerious]

To anyone reading this: THIS IS NOT A VULNERABILITY.

A local attacker can always do anything to your database. That is by design and simply how things work. KeePassXC is not an online service, so any additional password prompt could be circumvented. Also, there is no reason for an attacker to change your password. If they have access to your unlocked database, they have access to the data in it, no matter what the password is. They also cannot lock you out, unless you fail to do backups.

[phoerious]

I requested a rejection of the CVE with the following reason:

This issue is not a vulnerability. KeePassXC is an offline password manager and hence BY DESIGN, there is no such thing as an "authenticated user". Asking the user for their password prior to making any changes to the database settings adds no additional protection against a local attacker. An attacker can ALWAYS make changes to the database or copy its contents if they get access to it in its unlocked form. A password prompt will not change that. There is also no (and cannot be any) "second factor" for "authentication." Again, this is by design of an offline password manager and not a security problem. This is different from online web services. A password prompt does not even prevent an attacker from locking a user out of their database. If that were the attacker's goal, they would not need access to the unlocked database. Corrupting the locked KDBX file is enough to achieve this goal. The correct strategy to protect against this is keeping backups of the database. A password prompt will not help.

The premise of the CVE comes from a fundamental misunderstanding of KeePassXC's security model.

[svenseeberg]

I totally agree that this is not a vulnerability. KeePassXC already does include a much more suitable mitigation for the stated scenario: there is a setting to lock the database when inactive. The time can be set to a very short interval, if necessary.

[obitbef]

I totally agree that this is not a vulnerability. KeePassXC already does include a much more suitable mitigation for the stated scenario: there is a setting to lock the database when inactive. The time can be set to a very short interval, if necessary.

You name it as problem and suggest a mitigation. Why not resolve the problem?

• problem: no password is required for exporting the database in clear text
• solution: require the master password for exporting the database in clear text
• attack vector: attacker gains access to the unlocked database for a very short period of time and can perform a FULL clear text export. This can happen when an authorized user leaves the room and dont lock unfortunately.

[droidmonkey]

attacker gains access to the unlocked database

You have lost.

Adding a step prior to export or when changing the credentials would be nice feel good dressing and it might be a best practice for online services (which we are not). It does not prevent:

1. Copy / paste any entry's credentials into notepad
2. Auto-Type credentials into notepad
3. Cellphone picture of secrets exposed in the entry view
4. (My Favorite) Create a new database and then drag various groups, hold CTRL to copy, then drop into the new database. Walk away victorious.

What do these all have in common? You lost complete control over your unlocked database.

[obitbef]

4. (My Favorite) Create a new database and then drag the root group, hold CTRL to copy, then drop into the new database. Walk away victorious.

You can copy ALL entries within seconds in a new database with a password that you know. I forgot about this option. :-(

[phoerious]

You can also set up the root group to sync via KeeShare into another database, which is basically the same thing. And even though we could potentially ask for a password before syncing changes, I doubt anyone would want that, as it's a (frequent) background operation and being asked for your password every time kind of defeats the purpose of KeeShare.

[dr-br]

Who submitted this? https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-35866

I have the very strong impression, these guys (cybercitizen dot tech) are scammers.

EDIT:
In their "Blog" (only linked on the German page), they describe their "The Timeline of Vulnerablity reporting".

[phoerious]

I don't think he's a scammer, but the CVE is definitely not 'supporting' us. On the contrary, now we have to deal with all the bad tech journalism out there with their unverified cookie cutter news articles about a 'critical vulnerability in KeePassXC'. We already told him back then when he emailed us that this is simply how offline password managers work and not a vulnerability.

[droidmonkey]

There was no notice that an actual CVE would be submitted. That is extremely bad form and results in an extraordinary amount of work for us to cleanup the mess created. Also MITRE does no one favors with posting a CVE without any validation, confirmation, or notice to the maintainers. All around, this has been terrible.

[dr-br]

My impression: CVE's only purpose was to increase the reputation and gain visibility for this so called start-up. If you look at their blog, there is nothing substantial and nothing relevant. And only 3 entries. What upsets me is the bad press these pompous generate. BSI (german federal office for information security) and tech journalism, unfortunately, blindly spread this fake CVE.

[cmeh]

Just for your info, Germany's CERT-Bund (Computer Emergency Response Team for federal Government Agencies) has obviously issued a warning on this and several major IT news sources, e.g. heise are now picking up on it.

[phoerious]

I know. :unamused:

[dr-br]

Just for your info, Germany's CERT-Bund (Computer Emergency Response Team for federal Government Agencies) has obviously issued a warning on this and several major IT news sources, e.g. heise are now picking up on it.

I contacted BSI. You have to be concise, only 200 chars allowed in their contact form...

[droidmonkey]

Blog post made: https://keepassxc.org/blog/2023-06-20-cve-202335866/

[obitbef]

I'm not sure if this closed issue is the right place to discuss needs for security settings in KeePassXC. If not, feel free to move or delete this comment.

In the Blog post mentioned above it is said "KeePassXC is an offline password manager". I would say KeePassXC is the interface to access an encrypted database. If and how an action will be allowed or denied depends on the design of this interface.

Dangerous actions should be protected by the interface to avoid attacks in passing by. Which dangerous actions?

• all settings for database security
• all actions on entries (copy, delete, ...) which affects more than one entry
• all export actions and import actions too

Which protection?

• require the database password

I don't consider this to be "security theatre". It protects the database from bulk actions in case of an accidently not locked database. All other advices in the last paragraph of the blog post should be emphasized and followed.

[flowpoint]

Additional password entries can just be recorded by the attacker on the machine.

Imo, you cant prevent mass export without significantly impacting usability if at all. At this point you might aswell just use multiple databases with multiple passwords. Changing settings and deletion are covered by proper write-only backups to elsewhere.

[phoerious]

A good portion of what you deem 'dangerous' actions is just part of KeePassXC's normal set of user features. Requiring a password for each of them would make KeePassXC unusable or at least very annoying and features such as KeeShare would basically stop working as intended. In the end, it's indeed just security theatre, because all it does is make life harder for everyone while still not fully addressing the 'vulnerability'. Another unwanted side effect of additional password prompts may very well also be users choosing shorter and therefore less secure passwords.

If you want to protect yourself against accidentally leaving your database unlocked, set a (very) short lock timeout. If that is too annoying for you, then you wouldn't want a password prompt for each bulk action either.

[obitbef]

I suggest requiring the database password for bulk actions out of my daliy usage. I don't use KeeShare and do bulk actions or do exports or change database settings less than once a week. High frequently I'm getting one password entry at a time.

[phoerious]

Again: It does nothing for you. Enter * into your search bar and then "export" your whole database by typing sequences of Ctrl+C, Alt+Tab, Ctrl+V, Alt+Tab, Arrow down. There are tools to automate that in rapid succession.

And why would you even want to change the password of a database as an attacker? All you do is tell the owner you compromised their data.

[obitbef]

Is there any real chance to get security hardening for KeePassXC to protect from passing by attacks?

[phoerious]

KeePassXC has many mitigations against local attacker scenarios, even though in most cases you'd have simply lost anyway. We will not, however, add something that has very little value in terms of security, but a high impact on normal users. Don't want passers-by to access your database? Don't leave it unlocked. Don't want them to install a keylogger on your system? Don't leave your PC unlocked either.

[michaelkebe]

What about adding a reminder message/dialog/popup/whatever, to keep the device you are using secure and keep the database as short as possible unlocked?

This message should contain an checkbox with a message like "Don't show me in the future, I am aware of the security implications!". Then the impact on normal usage of experienced users is minimal.

[svenseeberg]

What about adding a reminder message/dialog/popup/whatever, to keep the device you are using secure and keep the database as short as possible unlocked?

Sure, this could be a "feature". However, that would also imply that browsers constantly tell you to log out your sessions? Text editors constantly ask you to protect all files with passwords? Yes, sure its all possible. But is it useful? Users will quickly be annoyed. And it's not like this info is not available to users ubiquitously. And in the end protecting processes from unwanted access is something that the OS is supposed to do.

[michaelk83]

Don't leave your PC unlocked either.

I think this is really the key advice. If you leave your unlocked PC unattended, an passer-by attacker could compromise your passwords and do a lot of other damage even if you don't have KeePassXC installed at all. KeePassXC is not your only concern in that scenario.

Get in the habit of always locking your session when you leave the PC, and set KeePassXC to lock when the session is locked. If you have other users who need to use the same machine, give them a separate account.

[fat-tire]

Just saw this on twitter and was at first slightly alarmed until I tracked down this issue and read the comments... yeesh.

[xantoniorx]

Enpass is an offline password manager, and it requires password for data export! If someone while working on the pc has a trojan on the PC without realizing it, it is easy to export the data unencrypted without being asked for a password.

You're saying so many arguments about not wanting to enter the password when exporting data. surely this feature would be a protection that improves the program.

Don't want to enter it? It doesn't matter i stay with enpass :-)

[cschweers]

@xantoniorx That explains a lot, of course ... It is not a report of a security vulnerability at all, it is a clever advertising campaign.

[phoerious]

Enpass is an offline password manager, and it requires password for data export! If someone while working on the pc has a trojan on the PC without realizing it, it is easy to export the data unencrypted without being asked for a password.

@xantoniorx Create a new vault, Ctrl+A select all entries in the old vault, right-click and select 'Add to Vault', select your newly created vault and click 'Copy'. No password required. Just tested it for you.

Don't want to enter it? It doesn't matter i stay with enpass :-)

Sure, stay there.

[obitbef]

@xantoniorx Create a new vault, Ctrl+A select all entries in the old vault, right-click and select 'Add to Vault', select your newly created vault and click 'Copy'. No password required. Just tested it for you.

Again: bulk operations must require the password 😃

[xantoniorx]

@xantoniorxQuesto spiega molte cose, ovviamente ... Non è affatto una segnalazione di una vulnerabilità della sicurezza, è un'intelligente campagna pubblicitaria.

I didn't advertise, I mentioned another offline password manager for comparison. I just wanted to make a suggestion. I close the question. Thank you :-)

[svenseeberg]

Again: bulk operations must require the password smiley

So you're saying that your file manager should ask you for your user password if you hit Crtl + A & Crtl + C because your copying too many files? Your text editor should lock your document when scrolling too many pages at once because someone could be creating a video and could be extracting information from a critical document? The browser should delete (session) cookies when switching between too many tabs?

Sorry, the foundation of your reasoning is a bit shaky.

[cschweers]

@xantoniorx

I didn't advertise, I mentioned another offline password manager for comparison. I just wanted to make a suggestion. I close the question. Thank you :-)

That is what you pretend to do, but not how you act.

[obitbef]

@svenseeberg

So you're saying that your file manager ...

I'm glad you ask. No I don't say this. I want to see my statement in context of password managers.

[svenseeberg]

I want to see my statement in context of password managers.

To protect you from what exactly?

attack vector: attacker gains access to the unlocked database for a very short period of time and can perform a FULL clear text export. This can happen when an authorized user leaves the room and dont lock unfortunately.

As many stated before: a bulk action password does NOT protect you against this sort of attack, for multiple reasons:

• You would have to consider all passwords compromised, even if only a few would be copied, because (most likely) you don't know which ones have been copied.
• There are still limitless possibilities to copy each password individually within a few seconds (keyboard/mouse macros, etc) that are almost all outside of the control of KeePassXC. Sure, copy & paste rate limits could be imposed as well. But how would that work with KeeShare? You need to come up with a solution for this as well.
• (At least) Your OS user is compromised now. The attacker can replace the start menu link to KeePassXC to a compromised executable, install a key logger (hardware or software), etc. Thinking that you're okay because you have a bulk action password in KeePassXC is simply wrong.

But then again: protecting a process from unauthorized access is something that the OS is supposed to to, including the screen lock. If security has to be improved here, OS vendors should be the first point of contact to impose more restrictive screen locking settings.

Abstractly I can see only one reason for a bulk action password: It would serve as a confirmation to a maybe(?) hazardous operation. But I do not see in which cases this would actually be hazardous.

[Demivan]

This is getting ridiculous.

Imagine you have a safe at home. You left it open. Now you want a safe company to add a feature to only allow getting one bill at a time from an open safe. This would be inconvenient - sure, but would that add any security? And your safe already has a feature that would automatically lock it after some time.

Just don't keep your safe (KeePass database) and house (PC) open.

[obitbef]

I leave this discussion and have learned a lot about the threat model of KeePassXC. Thank you to all for the explanations.

[phoerious]

An attacker getting their hands on an unlocked database is just bad. Full stop.

Even if they couldn't bulk-export everything at once and and even if one-by-one password copying were strictly rate-limited, they could look for individual high-value passwords and copy just those. For you as the owner of the database, it would still mean you would have to change each and every password. But most likely, you wouldn't, because you don't even know you were compromised and so the attacker could come again any time and steal another password of yours. Could we log any password access? Yes, we could, but then each simple read-only operation would be followed by a write operation, which creates a completely new massive bunch of big problems. And even then the attacker could just create a copy of the KDBX file before doing anything and restore it afterwards.

[droidmonkey]

Going to lock this since the conversation is robust and it might devolve quickly. Also since this issue is linked directly from the CVE and blog post.