Ok, your password database was affected by malicious modification. So what? How it can break the confidentiality of your data?
Update: By the way, what's wrong with the bytearray compare code snippet?
I have access to your kdbx db (ex. you sync to Dropbox and I'm Dropbox employee). I can alter the kdbx file to change your password so that it is no longer valid. KeePass doesn't complain at all.
You have a WTF moment and try to change your password over HTTP, while I inspect network packets and grab your new password.
You say "this is far-fetched, non-realistic scenario". I say "this is poor crypto design".
How are you generating a kdbx file that has the record where they think it is? The entire file is encrypted en-mass except the header.
You can certainly make a kdbx file that KeePass will open, but it is impossible to make one that will fool the user without more than enough information to just compromise the database.
It turns out that the kdbx on your private server got silently corrupted (ex. fs corruption) ~5 years prior to your death. However, your Dropbox backups only have 30 days of previous kdbx versions.
Can your Executor handle the disappointment?
I believe this issue is grave enough.
1) Random port is not helping against a specific attacker. Get a real firewall 2) Fail2ban is not a real firewall 3) Keys only, no passwords. 40chars is nothing compared to a strong rsa key with a 40char password on it
Though I won't speculate if it's a real problem here, since I have no idea what data is being compared.
The client (that decrypts the password database) runs on your local computer, and typically places clear-text-passwords into the clipboard during normal use. So if your local computer is compromised you have way bigger problems than timing attacks.
However most attack vectors on the local machine can usually get a hold of both keyboard and clipboard data making it impossible to prevent sniffing, but that does assume a sophisticated sniffer.
So when you submit a form the malware records what was in the form and just as important where that form was submitted to (i.e. what URL).
Without context (the where) the information (the what) is near worthless. Aside from toy malware nobody actually logs keys anymore, the term "keylogger" is just a word, it isn't literal.
Source: I have looked at the leaked source of commercial (in the black market) malware. A core part of this malware is automation for resale, nobody is going to read through hundreds of pages of someone's clipboard and keystrokes to figure out what page they're on, and it is by far a more difficult route than just breaking into the browser, hooking Win32 functions, or hooking into the network stack before encryption occurs.
If your adversaries are on your box while you operate your vault, then you have already lost because they will also have keyloggers, strace, etc.
If keeppass removes the possible timing attack, the attacker could just add it back in and use their own client, if they have a copy of your database.
Unfortunately, [KDBX4] introduces new vulnerabilities.
Similarly to KDB, the main problem of this format is
the lack of authentication of *hdr*. As such, is it
susceptible to modifications... This modification is
not detectable by the password manager... if a user
alters, and then saves, a corrupted database, all
passwords previously affected by the attack are lost
forever.
This attack highlights a remarkable design flaw. Even
an accidental bit-flip in the *pskey* field, e.g., due
to a transmission error, cannot be detected, and leads
to complete corruption of the database. Such
corruption is unlikely to be immediately detected by
users, who may subsequently add new entries. Over time,
the database will be composed of both correct and
corrupted entries, making it difficult to reconstruct
the damaged records from a backup.
Over time, the database will be composed of both
correct and corrupted entries, making it difficult
to reconstruct the damaged records from a backup.
EDIT: It looks like you can clear out all the comments and other stuff in the db and export to Keepass v1 CSV and you should be able to import from that.
Newer versions store a SHA-256 hash of the header inside the encrypted XML.
At least KeePass >= 2.20 and KeePassX 2.0 >= alpha3 support this. I haven't checked other implementations.