The Independent Security Evaluators (ISE) conducted a security audit of
1Password, Dashlane, KeePass, and LastPass on Windows 10,
The results are worrying. ISE
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dominik is correct, the method used was able to detect copies of sensitive data inside the memory created by the operating system itself, KeePass is unaware and cannot overwrite these copies.
this is an issue that Microsoft might have to address. qoute from the link:
"Windows and .NET may make copies of the data (in the process memory) that cannot be erased by KeePass."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What strikes me here is that in the case of 1Password 4 they only found the last recently used password in memory when unlocked and no used password when locked, and 1Password 4 is also distributed as a Windows application. The question naturally arises if that technique could be used in KeePass (which, after all, is the only Password Manager in that analysis without a red brick in theit summary table...).
Best regards and thanks for KeePass!
Florian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With respect to 1Password 4, ISE says [1]: "On the positive side, we found that as a user accesses different entries in 1Password4, the software is careful to clear the previous unencrypted password from memory before loading another. This means that only one unencrypted password can be in memory at once."
I've tested this on my own and cannot confirm ISE's statement. In my test, once a password has been displayed, it's visible in the process memory, and using other entries and locking the vault afterwards has no effect, i.e. the password remains visible.
In the test, the passwords of 3 entries (namely 'MyPassword_123AAA', 'MyPassword_123BBB' and 'MyPassword_123CCC') are first displayed, then hidden, and finally the vault is locked. Afterwards, all 3 passwords can still be found in the process memory.
Both 1Password 4 and KeePass are using standard Windows controls and thus have the same limitation. My guess is that in the 1Password 4 tests of ISE previously used passwords were freed and "accidentally" overwritten (which can also happen for KeePass). Based on my own test above, I see no evidence that 1Password 4 can intentionally erase copies that Windows makes. I'm not aware of any proper way how copies made by Windows can be erased; if you have an idea, please let me know.
Thank you very much Dominik for that demonstration.
The only idea to avoid the trouble with Windows Controls that comes to my mind ist to display passwords as graphics with the rendering process completely under KeePass' control instead of as text (field). They cannot be copied by Ctrl-C and editing is still unsolved unless a specialized control is implemented for that instead of a text field. This idea is possibly nonsense - I am not a security expert.
Cheers,
Florian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your idea isn't nonsense, but unfortunately it's not really feasible.
Implementing an own text box would require a huge amount of work (input cursor, selection, scrolling, activation states, right-to-left support, IME, support for special Unicode characters, surrogate pairs, DPI settings, etc.).
In fact, several people attempted this already, but all of them gave up. If you want to try it: KeePass has an infrastructure for plugins that want to implement a custom secure text box, see the 'CustomSecureTextBox' example plugin.
Sensitive data can also be displayed in list views (for instance in the main entry list) and rich text boxes (for instance in the entry details view at the bottom of the main window), so these would need to be reimplemented, too. This obviously would require even more work than reimplementing a text box.
Data transfers will continue to require unencrypted data in the process memory. For example, in order to copy data to the clipboard, KeePass must use the respective API functions provided by Windows, which permanently take ownership of the data, i.e. KeePass cannot erase it. Furthermore, most target applications don't have any process memory protection.
Best regards,
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I were a malware developer, the next feature added to my malware would be a string scan of RAM when any password manager is detected running. This is going to be an issue we should protect against. Perhaps we could (Optionally) let the user copy-paste the password in halves, and display the password in halves, from two text boxes, and we call windows to populate several other off-screen, red-herring text boxes with garbage-permutations of that password. This would provide some protection by requiring more work to reconstruct the password. Also, we might be able to force Windows to overwrite the memory holding the copy of the password by creating a large number of off-screen garbage text boxes once the copy-password time limit has arrived.
Last edit: Kevin Franklin 2019-03-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KeePass or any other password manager for that matter cannot protect you when the host is compromised.....
There are way easier ways to retrieve sensitive data. the "attack" here only managed to retrieve some passwords and not even the master password.
KeeFarce, Keethief & Lazanga all have official githubs with actual code that works on KeePass.
this is not an issue.. and it's not like Dominik can do something about that. It's a windows behaviour and limitation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those github projects are eye-opening! Thanks for sharing those. Wow.
I wouldn't say "this is not an issue" about the ram-scanning. I would say ram scanning is not as bad an issue as KeeFarce and friends. Right now, if there's a hostile app on your computer, you better not use your password manager. This is something the security evaluator article really should have put in their analysis conclusion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
They looked very generally on the KDF, on like what's being used.
the real thing is checking the actual code implementation, looking for possible issues.
they didn't talk about encryption,salt or PRNG which are extremely important to a quality encryption scheme.
for locked, all they did was dump the memory and look for strings.... ridiculous.
how do you see it, as deep dive into KeePass?
Last edit: John Jones 2019-02-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The topic was not to check the encryption itself but the framework around the program usage. That has nothing to to with a code review and of course they can't inspect the code of all this password managers (some code is not even free).
But if some memory contains the master password if the programs are locked
its a sign of possible improvements in the way memory is handled.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems like you didn't read it so I'll type it again:
"Windows and .NET may make copies of the data (in the process memory) that cannot be erased by KeePass."
The memory copies are not handled by KeePass but by Windows.
you can open a case for Microsoft on that, Good luck.
the attack shown here is ridiculous. the dump was done immediately after KeePass was closed and didn't launch any other programs that could have overwritten the memory
Last edit: John Jones 2019-02-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the attack shown here is ridiculous. the dump was done immediately after KeePass was closed and didn't launch any other programs
I don't see where you're getting that.
The paper explicitly said that DashLane in particular still had secrets hanging around in the process memory 24 hours after locking the database. I had the impression after reading the paper they did a similar analysis for other apps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry if I'm beating a dead horse. Does anyone know what these "modern Windows memory security techniques" are that KeePassXC claims to use that KeePass 2.x doesn't? https://keepassxc.org/blog/2019-02-21-memory-security/
Also, the original ISE report briefly mentions keyloggers and clipboard sniffers, but I wonder if they enabled KeepPass's Secure Desktop or TCATO features when testing. Maybe other password managers incorporate these so there's no point.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Both KeePass and KeepassXC overwrite sensitive memory spaces once they are no longed needed.
Unlike KeePass which is written in C# and utilizes the .NET framework KeePassXC is written in C++ which allows you to manually control and manipulate memory(low level language without much abstraction and garbage collection)
The whole point of this "Vulnerability" is pointless and is out of scope as it requires the host to be compromised.
In terms of KeepassXC vs KeePass, while C++ does allow tighter register/memory control it also allows for mistakes that can leak sensitive data.
KeePass was tested and analyzed several times, including today(active bug bounty)
something keepassXC can't say about itself...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KeePassXC assigns a discretionary access control list (DACL) to its process in order to make accessing the process memory harder. KeePass also has an option for this, but it can be turned on only by manually editing the configuration file, because it causes massive compatibility and stability problems. For details, please see the documentation (option 'Configuration/Security/ProtectProcessWithDacl'): https://keepass.info/help/v2_dev/customize.html#opt
ISE did not enable KeePass' secure desktop option and TCATO (see their report, section 'Scope').
Using a low-level programming language doesn't help solving the primary issues. For example, KeePass 1.x is written in C++/MFC and KeePass 2.x is written in C#/.NET, but both editions in the end are using standard Windows controls/APIs and thus have the same limitations (displaying or transferring a password makes it visible in the process memory and Windows' copies cannot be erased). In fact, this applies to all password managers that are using standard Windows controls/APIs, independent of the programming language.
Best regards,
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you please be more specific on DACL compatibility problems? What are the cases when DACL leads to hangs, exceptions or crashes? What the specific software may cause this?
The only problem I've encountered is the Punto Switcher doesn't work in the KeePass window, but it doesn't look so severe. The antivirus/firewall used is Comodo Internet Security.
I find the DACL-enabling option very useful, especially to prevent sandboxed (via Comodo or Sandboxie) applications from reading KeePass memory. Thanks for it!
(Update) I was wrong, Comodo Containment doesn't prevent the DACL-protected memory from being read, though seemingly Sandboxie does.
Last edit: kibinimatik 2019-04-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On compatibility problems: the DACL may prevent legitimate other software from working with KeePass. A few examples are mentioned on the documentation page.
When I've implemented this option, I moreover observed various application hangs, exceptions and crashes on some systems (not on all; it depends on the environment). Unfortunately, I haven't found out the exact conditions/causes for these problems.
If the option mostly works for you, feel free to leave it turned on. Keep the option in mind, and when you encounter crashes in the future, you know how to turn it off.
Given the possible problems, I don't want to make the option more accessible to users. If KeePass crashes right after the start, this can only be resolved by manually editing the configuration file; thus it makes sense to offer the option only by manually editing the configuration file from the first.
Best regards,
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The researcher from the white paper insisted that if u going to build some kind of security software u have to figure out an solution to prevent things like that.
Among other options, they pointed out the possibility to use the intel SGX technology to protect the memory over the hardware layer.
btw: Dominik how difficulit would be that for keepass to implement this ?
But i hink u have to look different over this topic cause some tools are open source and some are commercial.
So Keepass is maintaned by people around Dominik who doing this in thier freetime for free. and as far a i can estimate rightly there doing it very well.
On the contrary u have the companys which sell their Password Manager and get money for it.
And if i have to pay an annual fee i demand that some issuse will be fixed immediately.
best regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Independent Security Evaluators (ISE) conducted a security audit of
1Password, Dashlane, KeePass, and LastPass on Windows 10,
The results are worrying.
ISE
What they found is a well-known and documented limitation of the process memory protection.
The relevant documentation is here:
https://keepass.info/help/base/security.html#secmemprot
Thanks and best regards,
Dominik
Dominik is correct, the method used was able to detect copies of sensitive data inside the memory created by the operating system itself, KeePass is unaware and cannot overwrite these copies.
this is an issue that Microsoft might have to address. qoute from the link:
"Windows and .NET may make copies of the data (in the process memory) that cannot be erased by KeePass."
What strikes me here is that in the case of 1Password 4 they only found the last recently used password in memory when unlocked and no used password when locked, and 1Password 4 is also distributed as a Windows application. The question naturally arises if that technique could be used in KeePass (which, after all, is the only Password Manager in that analysis without a red brick in theit summary table...).
Best regards and thanks for KeePass!
Florian
With respect to 1Password 4, ISE says [1]:
"On the positive side, we found that as a user accesses different entries in 1Password4, the software is careful to clear the previous unencrypted password from memory before loading another. This means that only one unencrypted password can be in memory at once."
I've tested this on my own and cannot confirm ISE's statement. In my test, once a password has been displayed, it's visible in the process memory, and using other entries and locking the vault afterwards has no effect, i.e. the password remains visible.
Here's a video of my test:
https://keepass.info/filepool/1Password4_Mem.wmv
In the test, the passwords of 3 entries (namely 'MyPassword_123AAA', 'MyPassword_123BBB' and 'MyPassword_123CCC') are first displayed, then hidden, and finally the vault is locked. Afterwards, all 3 passwords can still be found in the process memory.
Both 1Password 4 and KeePass are using standard Windows controls and thus have the same limitation. My guess is that in the 1Password 4 tests of ISE previously used passwords were freed and "accidentally" overwritten (which can also happen for KeePass). Based on my own test above, I see no evidence that 1Password 4 can intentionally erase copies that Windows makes. I'm not aware of any proper way how copies made by Windows can be erased; if you have an idea, please let me know.
Best regards,
Dominik
[1] https://www.securityevaluators.com/casestudies/password-manager-hacking/
Thank you very much Dominik for that demonstration.
The only idea to avoid the trouble with Windows Controls that comes to my mind ist to display passwords as graphics with the rendering process completely under KeePass' control instead of as text (field). They cannot be copied by Ctrl-C and editing is still unsolved unless a specialized control is implemented for that instead of a text field. This idea is possibly nonsense - I am not a security expert.
Cheers,
Florian
Your idea isn't nonsense, but unfortunately it's not really feasible.
Implementing an own text box would require a huge amount of work (input cursor, selection, scrolling, activation states, right-to-left support, IME, support for special Unicode characters, surrogate pairs, DPI settings, etc.).
In fact, several people attempted this already, but all of them gave up. If you want to try it: KeePass has an infrastructure for plugins that want to implement a custom secure text box, see the 'CustomSecureTextBox' example plugin.
Sensitive data can also be displayed in list views (for instance in the main entry list) and rich text boxes (for instance in the entry details view at the bottom of the main window), so these would need to be reimplemented, too. This obviously would require even more work than reimplementing a text box.
Data transfers will continue to require unencrypted data in the process memory. For example, in order to copy data to the clipboard, KeePass must use the respective API functions provided by Windows, which permanently take ownership of the data, i.e. KeePass cannot erase it. Furthermore, most target applications don't have any process memory protection.
Best regards,
Dominik
If I were a malware developer, the next feature added to my malware would be a string scan of RAM when any password manager is detected running. This is going to be an issue we should protect against. Perhaps we could (Optionally) let the user copy-paste the password in halves, and display the password in halves, from two text boxes, and we call windows to populate several other off-screen, red-herring text boxes with garbage-permutations of that password. This would provide some protection by requiring more work to reconstruct the password. Also, we might be able to force Windows to overwrite the memory holding the copy of the password by creating a large number of off-screen garbage text boxes once the copy-password time limit has arrived.
Last edit: Kevin Franklin 2019-03-14
KeePass or any other password manager for that matter cannot protect you when the host is compromised.....
There are way easier ways to retrieve sensitive data. the "attack" here only managed to retrieve some passwords and not even the master password.
KeeFarce, Keethief & Lazanga all have official githubs with actual code that works on KeePass.
this is not an issue.. and it's not like Dominik can do something about that. It's a windows behaviour and limitation.
Those github projects are eye-opening! Thanks for sharing those. Wow.
I wouldn't say "this is not an issue" about the ram-scanning. I would say ram scanning is not as bad an issue as KeeFarce and friends. Right now, if there's a hostile app on your computer, you better not use your password manager. This is something the security evaluator article really should have put in their analysis conclusion.
That's nothing new.
https://keepass.info/help/base/security.html#secspecattacks
https://keepass.info/help/kb/sec_issues.html#keefarce
Best regards,
Dominik
Memory scanning with permissions is not something KeePass can deal with, it's simply out of scope.
once an attacker can modify the local files(keepass executable, configuration files) there's very little you can do to prevent a leak.
Also the analysis itself is shallow and pretty dull
I don't agree but may be you are the deep specialist for such analysis.
They looked very generally on the KDF, on like what's being used.
the real thing is checking the actual code implementation, looking for possible issues.
they didn't talk about encryption,salt or PRNG which are extremely important to a quality encryption scheme.
for locked, all they did was dump the memory and look for strings.... ridiculous.
how do you see it, as deep dive into KeePass?
Last edit: John Jones 2019-02-20
The topic was not to check the encryption itself but the framework around the program usage. That has nothing to to with a code review and of course they can't inspect the code of all this password managers (some code is not even free).
But if some memory contains the master password if the programs are locked
its a sign of possible improvements in the way memory is handled.
Seems like you didn't read it so I'll type it again:
"Windows and .NET may make copies of the data (in the process memory) that cannot be erased by KeePass."
The memory copies are not handled by KeePass but by Windows.
you can open a case for Microsoft on that, Good luck.
the attack shown here is ridiculous. the dump was done immediately after KeePass was closed and didn't launch any other programs that could have overwritten the memory
Last edit: John Jones 2019-02-20
I don't see where you're getting that.
The paper explicitly said that DashLane in particular still had secrets hanging around in the process memory 24 hours after locking the database. I had the impression after reading the paper they did a similar analysis for other apps.
Hi, is it possible to encrypt the records. While it seems a stretch, if in-flight and post close data status is secure were cool?
Hi guys,
Sorry if I'm beating a dead horse. Does anyone know what these "modern Windows memory security techniques" are that KeePassXC claims to use that KeePass 2.x doesn't?
https://keepassxc.org/blog/2019-02-21-memory-security/
Also, the original ISE report briefly mentions keyloggers and clipboard sniffers, but I wonder if they enabled KeepPass's Secure Desktop or TCATO features when testing. Maybe other password managers incorporate these so there's no point.
Both KeePass and KeepassXC overwrite sensitive memory spaces once they are no longed needed.
Unlike KeePass which is written in C# and utilizes the .NET framework KeePassXC is written in C++ which allows you to manually control and manipulate memory(low level language without much abstraction and garbage collection)
The whole point of this "Vulnerability" is pointless and is out of scope as it requires the host to be compromised.
In terms of KeepassXC vs KeePass, while C++ does allow tighter register/memory control it also allows for mistakes that can leak sensitive data.
KeePass was tested and analyzed several times, including today(active bug bounty)
something keepassXC can't say about itself...
KeePassXC assigns a discretionary access control list (DACL) to its process in order to make accessing the process memory harder. KeePass also has an option for this, but it can be turned on only by manually editing the configuration file, because it causes massive compatibility and stability problems. For details, please see the documentation (option 'Configuration/Security/ProtectProcessWithDacl'):
https://keepass.info/help/v2_dev/customize.html#opt
ISE did not enable KeePass' secure desktop option and TCATO (see their report, section 'Scope').
Using a low-level programming language doesn't help solving the primary issues. For example, KeePass 1.x is written in C++/MFC and KeePass 2.x is written in C#/.NET, but both editions in the end are using standard Windows controls/APIs and thus have the same limitations (displaying or transferring a password makes it visible in the process memory and Windows' copies cannot be erased). In fact, this applies to all password managers that are using standard Windows controls/APIs, independent of the programming language.
Best regards,
Dominik
Could you please be more specific on DACL compatibility problems? What are the cases when DACL leads to hangs, exceptions or crashes? What the specific software may cause this?
The only problem I've encountered is the Punto Switcher doesn't work in the KeePass window, but it doesn't look so severe. The antivirus/firewall used is Comodo Internet Security.
I find the DACL-enabling option very useful, especially to prevent sandboxed (via Comodo or Sandboxie) applications from reading KeePass memory. Thanks for it!
(Update) I was wrong, Comodo Containment doesn't prevent the DACL-protected memory from being read, though seemingly Sandboxie does.
Last edit: kibinimatik 2019-04-03
On compatibility problems: the DACL may prevent legitimate other software from working with KeePass. A few examples are mentioned on the documentation page.
When I've implemented this option, I moreover observed various application hangs, exceptions and crashes on some systems (not on all; it depends on the environment). Unfortunately, I haven't found out the exact conditions/causes for these problems.
If the option mostly works for you, feel free to leave it turned on. Keep the option in mind, and when you encounter crashes in the future, you know how to turn it off.
Given the possible problems, I don't want to make the option more accessible to users. If KeePass crashes right after the start, this can only be resolved by manually editing the configuration file; thus it makes sense to offer the option only by manually editing the configuration file from the first.
Best regards,
Dominik
The researcher from the white paper insisted that if u going to build some kind of security software u have to figure out an solution to prevent things like that.
Among other options, they pointed out the possibility to use the intel SGX technology to protect the memory over the hardware layer.
btw: Dominik how difficulit would be that for keepass to implement this ?
But i hink u have to look different over this topic cause some tools are open source and some are commercial.
So Keepass is maintaned by people around Dominik who doing this in thier freetime for free. and as far a i can estimate rightly there doing it very well.
On the contrary u have the companys which sell their Password Manager and get money for it.
And if i have to pay an annual fee i demand that some issuse will be fixed immediately.
best regards