An exploit can reveal your KeePass master password in plaintext(pcworld.com)
pcworld.com
An exploit can reveal your KeePass master password in plaintext
https://www.pcworld.com/article/1923963/an-exploit-can-reveal-your-keepass-master-password-in-plaintext.html
52 コメント
This is hardly scary at all to me because if you're on my machine it's most likely game over. If you can read process memory you can just sit there until I use an interesting password copied into the clipboard.
This is also the reason you always use full disk encryption: because you don't know what sensitive content might get sprayed into your files.
This is also the reason you always use full disk encryption: because you don't know what sensitive content might get sprayed into your files.
How about Taking a computer to a repair shop. The staff will have access to your computer and passwords
You are simply explaining why you don't give people your disk encryption password. It's a lot of access, and just about impossible to be sure there's not substantial valuable content in free space or swap on disk.
I’m saying if passwords are available to someone with physical access to a person’s computer, there are many situations when that physical access is had without the owner realizing their passwords are at risk
[deleted]
If you are copying your passwords into the clipboard, you've already failed at using a password manager. Might as well just use an unencrypted text file.
Depends on the threat. If you may have a keylogger than copying may bypass that. KeePass 2 can even spilt its auto typing between the keyboard and clipboard so neither has the whole secret.
I tried to do something more structured by enabling auto-typing or something (in KeepassX (not XC)). First thing I wound up doing was to auto-type the password into the next application, which was a chat program.
Openbsd encrypts it's swap by default, you can jump through a couple of hoops and encrypt your swap on linux. on windows, i don't know, however, if you have an encrypted disk your pagefile(if on that encrypted disk) will also be encrypted.
I went on a sort of deep dive of how swap partitions are encrypted. Most of the time the crypto block device is tied into the swap system, which makes a lot of sense, reusing layers and all that, That is how linux and freebsd do it. but openbsd is interesting. it uses 512KB blocks each with it's own encryption key, and once all references to a block are gone the key is discarded. so no guarantee but openbsd does try to lose anything that was put in swap as soon as possible.
https://man.openbsd.org/sysctl.2#VM_SWAPENCRYPT~2
https://man.openbsd.org/sysctl.2#VM_SWAPENCRYPT~2
On Windows the swap FILE is encrypted if the partition is stored into is encrypted.
Same with the hibernation file, Bitlocker will require your password again (if it has one) on resume.
Same with the hibernation file, Bitlocker will require your password again (if it has one) on resume.
> Still, it does require the attacker to either have root on your machine or physical access to your disk. If the attacker has root on your machine, it's game over anyway.
How does Windows enforce signing these days? If I run "keeppass_compiled_by_attacker.exe" do you get some sort of prompt?
Without it, even with local user access it's kind of "game over"; there's nothing preventing the attacker from replacing the desktop or start menu shortcut to their own wrapper or own version which steals the master password. No modification of system files or special access to memory or whatnot needed.
And even with it, many users will likely just click through the warning.
On Linux and other Unix-like system this is certainly an issue.
Sometimes I think people are a bit too focused on these kind of complex and advanced exploits, while in reality it turns out you often don't need them to do malicious stuff.
How does Windows enforce signing these days? If I run "keeppass_compiled_by_attacker.exe" do you get some sort of prompt?
Without it, even with local user access it's kind of "game over"; there's nothing preventing the attacker from replacing the desktop or start menu shortcut to their own wrapper or own version which steals the master password. No modification of system files or special access to memory or whatnot needed.
And even with it, many users will likely just click through the warning.
On Linux and other Unix-like system this is certainly an issue.
Sometimes I think people are a bit too focused on these kind of complex and advanced exploits, while in reality it turns out you often don't need them to do malicious stuff.
>KeePassXC... which are other password managers compatible with KeePass database files, are not affected according to vdohney.
Great.
Great.
Yes, that's the one I use anyway. Great integration with most Linux desktops - a keyboard shortcut brings the target window to the top and enters the username and password right into the proper fields.
Although KeePassXC offers better process memory protection, it also can not help if you hibernate and the memory is written to disk.
Hardware password managers exist and are not so inconvenient.
Hardware password managers exist and are not so inconvenient.
Not that it is a panacea, but you can/should configure Keepass to autolock the database after inactivity. I believe the default is something like 4 minutes, which should kick in before any kind of hibernation or paging would occur.
Then you have to type the whole password again or your auto-type and plugins don't work. If you keep it open all day for random login needs then this can be a hassle.
Full disclosure, I sell a paid KP2 plugin to soft lock the UI. (It won't protect memory or dumps but does prevent naive snooping.)
Full disclosure, I sell a paid KP2 plugin to soft lock the UI. (It won't protect memory or dumps but does prevent naive snooping.)
Isn’t that a mostly moot point if you also use full disk encryption like File Vault?
Isn't it usually set to re-lock on screen lock (which typically happens before hibernate)?
The source is https://www.bleepingcomputer.com/news/security/keepass-explo... (as referenced in the article). It goes into more technical detail, and skips the antivirus sales pitch.
Mods: the title should be changed to make it clear it's the KeePass app for Windows, not the KeePass vault format as used by many applications. It is not an exploit Keypass which is the encrypted vault used by many applications - but a single client.
The actual vulnerability:
> KeePass 2.X uses a custom-developed text box for password entry, SecureTextBoxEx. This text box is not only used for the master password entry, but in other places in KeePass as well, like password edit boxes (so the attack can also be used to recover their contents).
> The flaw exploited here is that for every character typed, a leftover string is created in memory. Because of how .NET works, it is nearly impossible to get rid of it once it gets created. For example, when "Password" is typed, it will result in these leftover strings: •a, ••s, •••s, ••••w, •••••o, ••••••r, •••••••d. The POC application searches the dump for these patterns and offers a likely password character for each position in the password.
https://github.com/vdohney/keepass-password-dumper
> KeePass 2.X uses a custom-developed text box for password entry, SecureTextBoxEx. This text box is not only used for the master password entry, but in other places in KeePass as well, like password edit boxes (so the attack can also be used to recover their contents).
> The flaw exploited here is that for every character typed, a leftover string is created in memory. Because of how .NET works, it is nearly impossible to get rid of it once it gets created. For example, when "Password" is typed, it will result in these leftover strings: •a, ••s, •••s, ••••w, •••••o, ••••••r, •••••••d. The POC application searches the dump for these patterns and offers a likely password character for each position in the password.
https://github.com/vdohney/keepass-password-dumper
Well, yes. This is a known vulnerability of SecureString, and there is no true work around that I'm aware of. At some point, the string will be in memory, and this is why securestring isn't a recommended solution as much
First significant vuln for KeePass in awhile. Still a better threat model than cloud.
I think it's time to change the 90s-inspired security recommendations.
I work from home. I feel much safer with my password written on a piece of paper than with a password manager. God forbid the password manager is cloud-enabled.
I work from home. I feel much safer with my password written on a piece of paper than with a password manager. God forbid the password manager is cloud-enabled.
The whole concept of "my password" is horribly insecure, as if you use the same password everywhere, there is a big risk that one of the sites leaks your password and then all your accounts are compromised. Whatever risks a cloud-enabled password manager has, reusing a single password is so much worse that those things aren't even comparable.
Having all your passwords on a piece of paper could be safer than a password manager, but it's so inconvenient to store a hundred different random passwords this way that people simply won't do it and will reuse passwords. So if password managers get people out of the password reuse trap, they're a net gain in security, that far outweighs all the password manager risks.
Having all your passwords on a piece of paper could be safer than a password manager, but it's so inconvenient to store a hundred different random passwords this way that people simply won't do it and will reuse passwords. So if password managers get people out of the password reuse trap, they're a net gain in security, that far outweighs all the password manager risks.
To be more specific I use a system with 3-part passwords.
The first part is generated from the website/system.
The second part is the code phrase - this is the part that I need to remember (and for passwords I use rarely - that I need to write down).
The 3rd part is changing predictably every time the system is forcing me to change my password.
The stuff I am writing down I'm writing using a script I created long ago for my TTRPG. It's not hard to decrypt if you had whole pages of it, but it's not a trivial substitution. I used it as a puzzle in my D&D campaigns for friends (including people with PhD in CS and MA in math) and they couldn't solve it over several weeks without a lot of hints. I don't think a random guy who broke in will solve it looking at a piece of paper with 10 or 30 symbols.
The first part is generated from the website/system.
The second part is the code phrase - this is the part that I need to remember (and for passwords I use rarely - that I need to write down).
The 3rd part is changing predictably every time the system is forcing me to change my password.
The stuff I am writing down I'm writing using a script I created long ago for my TTRPG. It's not hard to decrypt if you had whole pages of it, but it's not a trivial substitution. I used it as a puzzle in my D&D campaigns for friends (including people with PhD in CS and MA in math) and they couldn't solve it over several weeks without a lot of hints. I don't think a random guy who broke in will solve it looking at a piece of paper with 10 or 30 symbols.
This is definitely reasonable if you like to use readable and easily-typed passwords (like Diceware/"correct horse battery staple"-style). A software password manager has an advantage for long, completely random, absolute gibberish passwords, because you don't even have to know what it is: you can just copy-paste or autofill it.
Another advantage of autofill is that it's more resistant to phishing attacks.
You aren't avoiding this problem though, just like this exploit requires physical access to disk, someone with physical access to your piece of paper negates any benefits. Even worse when people are recommending keeping your passwords in your wallet, something people lose quite often and due to cash interest there's a high incentive to stealing.
That doesn’t solve the problem of having 40 different passwords, at least half of which have to be changed on a regular basis, NIST guidelines be damned.
That just turns your piece of paper into a password manager that isn't secured with a password and doesn't require access to your device. I think the best option is an offline password manager on the device, and a hard copy of important passwords saved in a safe deposit box. The hard copy should be safe enough most of the time, and so should the copy on your device unless that device is already compromised or in the hands of attackers in which case, it's game over anyway.
No worries about the cloud that way, and you're free to use whatever means you're most comfortable with to handle updating databases between devices, but it does leave you on the hook for keeping and maintaining regular backups.
No worries about the cloud that way, and you're free to use whatever means you're most comfortable with to handle updating databases between devices, but it does leave you on the hook for keeping and maintaining regular backups.
Aren't you incredibly vulnerable to Credential Stuffing (https://en.wikipedia.org/wiki/Credential_stuffing)?
Special password books exist.
https://www.amazon.co.uk/password-book/s?k=password+book
Often people will mock them on social media for the likes, but actually in some circumstances ... I think they are the best option.
(They can be made stronger too - tell people to remember one word that they put in front of all their passwords but don't write down, like "cat". Then anyone who steals the book can't use it but they are still using different passwords for each site.)
https://www.amazon.co.uk/password-book/s?k=password+book
Often people will mock them on social media for the likes, but actually in some circumstances ... I think they are the best option.
(They can be made stronger too - tell people to remember one word that they put in front of all their passwords but don't write down, like "cat". Then anyone who steals the book can't use it but they are still using different passwords for each site.)
I have always felt the same. For me it is easy enough to have a little password book with everything written down. People often say what happens if there is a fire. I don’t have an answer to that but I have made it over 4 decades and not once had a fire so I’m going to believe the odds are I will not ever have a fire and chance it. Most things are recoverable with my phone number these days anyways. A much greater risk would be someone gaining access to my phone
If you have a fire, you'll just do what my wife does with _every_ password field she needs to use. You'll press the "forgot password" button.
God help her if she needs to log into her email after I'm dead.
God help her if she needs to log into her email after I'm dead.
[deleted]
I think Bruce Schneider recommended that most people should just keep their password in their wallet.
Source: https://www.schneier.com/blog/archives/2005/06/write_down_yo...
But he also wrote his own password manager: https://www.schneier.com/academic/passsafe/
But he also wrote his own password manager: https://www.schneier.com/academic/passsafe/
Windows has protected memory APIs to protect against precisely this kind of vulnerability. A simple method is to mark the "secure string storage" area as locked in memory, and hence not eligible for paging to disk.
Vulnerable vs not list, to make it more prominent:
>All existing versions of KeePass 2.x (e.g., 2.53.1) are affected. Meanwhile, KeePass 1.x (an older edition of the program that’s still being maintained), KeePassXC, and Strongbox, which are other password managers compatible with KeePass database files, are not affected according to vdohney.
>All existing versions of KeePass 2.x (e.g., 2.53.1) are affected. Meanwhile, KeePass 1.x (an older edition of the program that’s still being maintained), KeePassXC, and Strongbox, which are other password managers compatible with KeePass database files, are not affected according to vdohney.
Isn't it a bit unusual to release the details of an exploit before a fix is released?
The author of the software seems to be cooperating to release a fix, I would think making it public would help people who would exploit this maliciously.
The author of the software seems to be cooperating to release a fix, I would think making it public would help people who would exploit this maliciously.
[deleted]
Would it?
It need admin access to dump process memory. Those can do that are doing it already.
It need admin access to dump process memory. Those can do that are doing it already.
Perhaps it is possible to avoid having the plaintext in memory at all?
- Only compare the crypttexts, never the plaintexts
- For input use a modified input field to minimize the time the plaintext kept in memory then wipe the memory used by the input field before releasing the memory
- If possible ask the OS never to swap the memory used by the input field
- Only compare the crypttexts, never the plaintexts
- For input use a modified input field to minimize the time the plaintext kept in memory then wipe the memory used by the input field before releasing the memory
- If possible ask the OS never to swap the memory used by the input field
I'm a little surprised the article doesn't mention using a key file in conjunction with a password as an added security measure.
This is not a vulnerability because once you have the same privileges as the user, the game is over.
Still, it does require the attacker to either have root on your machine or physical access to your disk. If the attacker has root on your machine, it's game over anyway. You can mitigate the threat of recovering the password from your disk by using disk encryption.
Even when I hear about KeePass vulnerabilities, they're always substantially less severe than the attacks we see on LastPass and other web-hosted password managers where an attacker can exfiltrate bulk credentials at once by compromising a server.