4 ms·

KeePass disputes vulnerability allowing stealthy password theft

28 points by archb 4y ago

parasense 4y ago
I actually agree with the KeePass devs. There are two levels of local compromise, root compromise, and user level compromise. Both are really bad for the user, but if the root access was cracked then we can assume there is a key-logger at the dev/tty level tracking all keystrokes. If it's the user-level then we can assume all home dir files are exploited. There are shades of grey here, because if the user runs a flatpak the app cannot be replaced so easy, but config files can be changed. I would imagine the database file could be setup to bundle the config file, or even take a hash of the config file to be kept encrypted. But still, it would not be too much of a stretch to presume any version of the program could be run under a debugger to capture input, regardless of config files.
briHass 4y ago
I'd recommend going (and I do) one step further: lock down the KP config file, and especially the keyfile (definitely use this in addition to a password), to admins only and set the .exe to launch as administrator. The .exe is signed, so at least you have some guarantee it hasn't been modified. Plus, the UAC prompt doesn't look scary like it does for unsigned exes. The password DB (kdbx) can have standard access permissions so it works with whatever sync/backup (Google Drive, Dropbox, etc) you want to use. It's worthless without the keyfile. Executables running as administrator have all sorts of protections from other processes in user-land, and most importantly, the keyfile (locked to R/W only by admin) can't be Xcopy exfiltrated by a bog-standard malware process accidentally launched by clicking the wrong thing. It never made sense to me why this isn't a common recommendation. To me, my password DB, and especially the keyfile and/or the process that decrypts the secrets in memory, are the most important things on my device. Those belong at the highest level of security an OS can offer, not running at the same level as some crap I downloaded from the internet. I know KeePass also offers Windows DPAPI as an additional option (encryption at the user level.) It's been a while since I've dug into DPAPI, but that may offer additional advantages as long as Windows doesn't allow the RSA private key for a user to be extracted running as that user. That, of course, has the significant disadvantage of not being portable, and you better backup that RSA key.

28 points by archb 4y ago

I actually agree with the KeePass devs. There are two levels of local compromise, root compromise, and user level compromise. Both are really bad for the user, but if the root access was cracked then we can assume there is a key-logger at the dev/tty level tracking all keystrokes. If it's the user-level then we can assume all home dir files are exploited. There are shades of grey here, because if the user runs a flatpak the app cannot be replaced so easy, but config files can be changed. I would imagine the database file could be setup to bundle the config file, or even take a hash of the config file to be kept encrypted. But still, it would not be too much of a stretch to presume any version of the program could be run under a debugger to capture input, regardless of config files.

briHass 4y ago

I'd recommend going (and I do) one step further: lock down the KP config file, and especially the keyfile (definitely use this in addition to a password), to admins only and set the .exe to launch as administrator. The .exe is signed, so at least you have some guarantee it hasn't been modified. Plus, the UAC prompt doesn't look scary like it does for unsigned exes. The password DB (kdbx) can have standard access permissions so it works with whatever sync/backup (Google Drive, Dropbox, etc) you want to use. It's worthless without the keyfile. Executables running as administrator have all sorts of protections from other processes in user-land, and most importantly, the keyfile (locked to R/W only by admin) can't be Xcopy exfiltrated by a bog-standard malware process accidentally launched by clicking the wrong thing. It never made sense to me why this isn't a common recommendation. To me, my password DB, and especially the keyfile and/or the process that decrypts the secrets in memory, are the most important things on my device. Those belong at the highest level of security an OS can offer, not running at the same level as some crap I downloaded from the internet. I know KeePass also offers Windows DPAPI as an additional option (encryption at the user level.) It's been a while since I've dug into DPAPI, but that may offer additional advantages as long as Windows doesn't allow the RSA private key for a user to be extracted running as that user. That, of course, has the significant disadvantage of not being portable, and you better backup that RSA key.