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 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".