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 notice that the "change-password" function of yourbank.com is accidentally being served over HTTP instead of HTTPS. I just need to trick you into changing your password.
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".
Wait, you just inserted an invalid password in my database, how do I change my password? Hell, the only way I'll even realize something's wrong is by trying to log in in the first place, and, if you can see my connection, why would you have me enter a wrong password, rather than the right one?
I think he's suggesting that you happen to actually know the right password, and will attempt to enter it after the failed keepass attempt? But then, if you know the right password, you could also visually inspect the keepass data to know it was wrong.
> I can alter the kdbx file to change your password so that it is no longer valid.
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.
I have a private server in a datacenter that I put together myself. I use sftp to download/upload my keepass file, I also use a keyfile that stays local and a password for auth. What is the attack vector there?
You store u/p to your Lawyer's website, which has a copy of your Will. You die and the Executor of your Estate tries to access the Lawyer's website, only to be met with "invalid password".
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.
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
I must admit, I can't immediately see the problem with leaking timing data.
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.
It does have a mode that allows you to avoid clipboard sniffers if the program you are targeting supports it.
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.
The vast majority of modern malware no longer monitors either the clipboard OR keyboard. It hooks right into the browser or sometimes network stack.
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.
Confidentiality isn't your only concern. You should also be worried about integrity and availability. From "On The Security of Password Manager Database Formats":
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.
Which reminds me - I need to migrate back to Password Safe as soon as possible.
Confidentiality is my only concern in the case of malicious modification. Remember, that availability and integrity of your database can be broken without an attacker, just due to hardware problem, for example. So it is up to you to have a cold backup for such a critical asset.
Over time, the database will be composed of both
correct and corrupted entries, making it difficult
to reconstruct the damaged records from a backup.
I don't know enough about cryptography to be able to say whether it's possible to break a particular cryptographic protocol by blindly altering the ciphertext, but I do know plenty about human nature and backups. It's _highly_ unlikely that normal people keep more than a handful of backups. My own personal backup retention limit is on the order of 30 days, and that's with careful planning. Silent, on-going data corruption happening to a password database seems like a very reasonable thing to concern oneself with, especially if one's expectation was that the password manager would throw some kind of data integrity error whenever said database was accessed.
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.
I broke into your e-mail and need to get you to force a password reset on some other account, so I maliciously modify to give you an invalid stored password.
If the attacker already has control of the email address, they can reset the account without going to such lengths--just visit the site and request a password reset.
