security [NEWS] Some Password Managers Expose the Data they're Designed to Protect

[Phylum]

I ran across an interesting article about some other well-known password managers out there, like 1Password, KeePass, DashLane & LastPass.

• https://www.securityevaluators.com/casestudies/password-manager-hacking/

If that's too technical, read ZDNet's summary on this article:

• https://www.zdnet.com/article/critical-vulnerabilities-uncovered-in-popular-password-managers/

While I was pleased Enpass wasn't on the list, I suspect it might be due to lack of significant market share like some of the other products.  But I'm also very curious about the steps Enpass is taking to have independent third-parties pen-test the product. 

EDIT: I should have looked harder as Enpass has been audited in November of 2018!
Audit results: https://dl.enpass.io/docs/EnpassSecurityAssessmentReport.pdf
Security-related documents: https://www.enpass.io/?s=security&post_type=kbe_knowledgebase

Please do not misconstrue what's being said here!  I moved to Enpass several years ago, from KeePass which is mentioned in the article, and I am still very pleased with Enpass.  So pleased that I have purchased it for family members and and strongly urged friends & coworkers who do not have a password manager to give Enpass a shot.  The number one issue I hear about these other services is where that data is stored, and Enpass provides a great solution for data management since it builds on other well-known, and mostly trusted, storage products like Google Drive, OneDrive, DropBox etc.

In any event, kudos to the Enpass team for the fantastic work they've been doing over the years, especially on v6.x.  It's fantastic and I'm excited about what's next!

Edited February 21, 2019 by Phylum
Added security assessment link

[Vinod Kumar]

Hi @Phylum,

Sorry for the late response. Let me assert that, severity of this kind of attack is low, given the nature of the permissions, attacker requires to exploit it. This attack is only possible on a compromised system where an arbitrary process can read other process' memory and process memory protection is operating system's responsibility.  A password manager or another user-space process can't defend against such attacks.

However, we have taken some steps to mitigate this kind of attack. This was one of the reasons to rewrite Enpass 6 entirely with a new, robust architecture. Please check the Security Audit report where this issue appeared and resolution was provided by us (page 5).

Enpass is composed of two parts, Core and UI. The Core part is entirely in C++ and we have done extensive memory sanitization there. Almost always, UI part is responsible for leaking secrets because once an item is displayed in UI, we don't have control over its internal UI buffers. We have to depend upon garbage collector of framework/language to finish the work. One possible solution is to create custom controls for everything related to password and here is what we have done in various scenarios:

1. Master password is always scrubbed just after unlocking your database or usage on any other screen. Our custom editor control for master password input ensures this. You will almost never find a trace of master password in memory.
2. Only the password, you are currently interacting  is loaded into memory and scrubbed after its usage. The UI control to view a password is a custom control.
3. Editing passwords - This is the only time we use stock UI control to edit item password. For better user experience, we are not using the same custom control we use for master password. This password may or may not be found in the dump depending upon when it was freed by framework.

Security is an ongoing process and we continuously improving our software in every aspect, memory sanitization being one of them. We are working on bringing in custom controls in more leakage points.

Thanks.

[qalisto]

Vinod- This means that those of us who are users of PORTABLE versions and are forced to wait for ENP v6 for Portable Windows now become more worried.

Please rate the risk of using ENP 5.6.10 [portable] while your Devs work on the promised v6.

Thank you.

REF: SEE:  http://tinyurl.com/y6anrlnj
http://tinyurl.com/y4sngxl5

Edited February 27, 2019 by qalisto

[Vinod Kumar]

 

Hi @qalisto,

Thanks for bringing this up. With our current portable offering, situation is no better than what has been reported in said news article. While the master password is correctly wiped but other credentials do show up in memory. Blame the old architecture and choices we have made in past.

In an ideal world, we would have released portable version alongwith regular version of Enpass 6. Due to resource constraints, we were unable to do so. 

Good news is that, portable version has been merged with latest stable version and QA has been started.

Thanks.

[Domi]

On 2/26/2019 at 1:26 PM, Vinod Kumar said:

Enpass is composed of two parts, Core and UI. The Core part is entirely in C++ and we have done extensive memory sanitization there. Almost always, UI part is responsible for leaking secrets because once an item is displayed in UI, we don't have control over its internal UI buffers. We have to depend upon garbage collector of framework/language to finish the work. One possible solution is to create custom controls for everything related to password and here is what we have done in various scenarios:

1. Master password is always scrubbed just after unlocking your database or usage on any other screen. Our custom editor control for master password input ensures this. You will almost never find a trace of master password in memory.
2. Only the password, you are currently interacting  is loaded into memory and scrubbed after its usage. The UI control to view a password is a custom control.
3. Editing passwords - This is the only time we use stock UI control to edit item password. For better user experience, we are not using the same custom control we use for master password. This password may or may not be found in the dump depending upon when it was freed by framework.

This is impressive and amazing to read, especially if you're a developer and you know exactly how much effort it takes to prevent such memory leaks. Developing UI controls from scratch and skipping on stock / framework UI controls to ensure security is quite a thing. Thanks!