Jump to content
wachschaf

Data Security of Enpass in times of Meltdown and Spectre

Recommended Posts

Hello Enpass-Team,

happy new year to you! I'm a very happy user of Enpass and it's perfect usability. 

But since some week's I'm frightened about the usage of password-managers because of the released information regarding Meltdown and Spectre (CVE-2017-575,  CVE-2017-5715  and CVE-2017-5753)

Especially Meltdown can lead to a dump of the Memory of Applications like Password-Managers, which are one of the most valuable targets! I know, that MicroCode-Workarounds for CPUs and OS-BugFixes are on the way, but I want to ensure, that you have implemented Enpass in a way, to minimized the possibility to extract our passwords via such vulnerabilities.

Can you please give us some information, how you protect our data against such issues? 

For example:

When do you decrypt the passwords and store it in RAM? - When the user unlocks enpass, or when the user requests one specific password? Do you decrypt always all passwords or only the one which is requested? I know you use SQLCipher as backend. Does this mean, that always the whole Database is decrypted after unlocking enpass?

Please let us know some details. This is very important, especially as long as no audit of enpass exists.

 

Thanks in advance for you detailed explanation,

    wachschaf

Share this post


Link to post
Share on other sites

Hi @Akash Vyas,

this is really frightening to hear! This means, also if enpass is locked via pin, the password's still remain DECRYPTED in the memory (RAM)?! 

In this case, the vulnerability of Enpass is much higher than I have expected!!! Especially if every malware / virus which uses a high critical security gap like Meltdown can access other processes memory!

Sorry, this is absolutely unacceptable for a highly critical sw like a password manager! How far are the attempts grown to refractor enpass, which were mentioned by @Hemant Kumar in your referenced discussion? 

Best regards,

wachschaf

Share this post


Link to post
Share on other sites

Hi @Akash Vyas,

The answer from @Hemant Kumar in the post you linked, "Security Concern", is seriously worrying, not so much because of the huge security hole it reveals, but because of the careless reaction of @Hemant Kumar and Enpass : "Sorry, not our fault, it's the third-party applications we use". No, sorry, the true answer is "it's the third-party applications we use carelessly." You are responsible of how carefully you choose these third-parties, you are also responsible of how you use them so they don't create security holes in an application where security is critical, and you are finally responsible to audit your code, the third parties, and how they interact because, third parties or not, the result is the Enpass' solution, not Qt's, not SQLCipher's. I'm not saying that to blame, but to make your software engineers react and change their approach. When you're good, like in UX, you're really good, the best in my opinion. When it is not your strength, just look what others (open-source) do, and borrow the best solutions. Enpass doesn't have to be better at everything. As good as everyone else for most of it, but the best UX you can find, is enough to make people choose Enpass. But you need to be "as good as" for the rest, like security.

I hope you are not offended by my reaction, and you take it as an encouragement to do better, which it is. Here are some hints to make Enpass better, for free ;-)

The problem mentioned by @Hemant Kumar has been known for more than 10 years, and the solutions are fairly simples, no need to spend months rewriting everything in C/C++ and let your customers' data exposed during this time :

Memory encryption: Encrypt all data in your own core before you send it to a third-party storage, even if the storage calls itself "secure", and keep all data encrypted in memory until the very last moment (more on that later). Enpass doesn't do intensive data processing, so the delay of this double encryption (storage and memory) won't even be noticeable. Also, to make the storage searchable, encrypt each word of the entry titles separately. This way, if we search Enpass, the storage will be able to return the "Enpass" entry as well as the "Enpass Forums" entry. You should also give the option to store everything double-encrypted except the title, if someone want to keep the "search as you type" functionality. Ideally, this option should be configurable by type of entry, like having web site titles not encrypted but credit cards title encrypted. An algorithm like ChaCha is really fast, secure, independently audited, and free. It would probably be the best for memory encryption. You can also use ChachaPoly when you transfert encrypted data between modules (f.e. between the main app and a browser extension) so you have both encryption and authentication, to avoid a rogue browser extension to spoof a Enpass extension, or any similar attack. For both, open-source libraries exist in several languages, so not too much effort to implement.

Key storage: First, use different keys for storage encryption and memory encryption. They can be derived from one another with a salt, but don't use the same, this is important for OSes that do not provide secure memory. Whenever possible, store the keys you use for memory encryption in the secure memory provided by the OS when the key is not in use. Never keep it in memory, until you actually need to decrypt a chunk of data. Once again, the delay of requesting the key from the secure memory every single time will not introduce any significant delay. This may require to rewrite this part of your code for each OS, since the secure memory API differs on each OS, but it should be a very small part of your code. You should also have your own "secure" memory storage for OSes that do not have a secure memory API. Once more, no need to reinvent the wheel, there are solutions available in open-source. Just make your "secure memory storage" a library, so you can keep the rest of your code closed-source. Sure, if the OS does not provide a secure memory API, the memory encryption key will still be directly or indirectly exposed in memory but, at least, our most confidential data will not be exposed to any 6 years old kid. Plus, on all the OSes that take security seriously (most of them), and provide a secure memory API, we'll be reasonably safe.

Harware encryption: A lot of hardware platforms now offer hardware encryption and OSes provide APIs to use them. It would be an even better solution as it limits how long you need to expose the memory encryption key. Store it in the hardware encryption chip when Enpass starts, erase it from memory then decrypt in the hardware encryption chip when a piece of data is needed. Common hardware encryption/decryption chip have a limited throughput but, after all, we only need one password at a time, we can wait an additional milli-second. Of course, this means dropping Chacha for memory encryption and use something more commonly implemented in hardware encryption, like AES-256. While AES-256 is considered "weak" compared to ChaCha, it is still a reasonably strong encryption for temporary use like memory encryption, and the advantage of not storing the key in memory largely overcome the potential "weakness" of AES-256.

Data persistance: Only decrypt data in memory when absolutely necessary (such as showing a password or auto-login) and keep the data encrypted until the last step (decrypt in the browser extension when auto-logging, not in the main Enpass). Also, only decrypt one piece of data at the one time, for example decrypt the login, use it and erase it, then decrypt the password, but not both at the same time. Your UI should hide, and therefore not need anymore, the other fields when showing the password, so you never need all the encrypted data of one entry at the same time. For auto-logging, offer the option of multiple transfer methods for the logging, like a mix of clipboard and key entry, so a key logger, or clipboard logger will never have the complete information (once again, available in open-source). Finally, overwrite the fields of every third party objects as soon as the data is not needed anymore, and of course before closing the object. This way, if the third party keep the object in memory even after you closed it, it doesn't contain sensitive information anymore. And, please, audit the memory after you implemented any of these solution to make sure it actually remove the sensitive information from memory as soon as it is not needed anymore.

All this can be implemented with the third parties you currently use, modifying only your own core. You are not the only multi-platform password manager who have faced the security issues caused by relying on third-parties, and other multi-platform password managers have addressed these exact issues more than 10 years ago. A lot of these solutions are even open-source (like Keepass or others) so you have no excuse not to implement them immediately without reinventing the wheel. If you still believe that all-closed-source is the only way to go, which it isn't, recode in your own way the concept developed and tested in the open-source projects, so you can make it closed source . But I strongly suggest you make Enpass a mix of open-source libraries and closed-source core, use every good open-source solution that exists, as is whenever possible, or create a new open-source library if you don't like the existing API, and only keep the core of Enpass, where your competitive advantage is, closed source.

No solution will be perfect, as a password manager will always have to decrypt and store in memory some confidential information when it needs to use it. But there are solutions to minimize the risk, only expose these information when needed, only for as short as needed, and never all the information that makes a complete login at the same time.

Seriously, I can't believe, in 2017, a password manager who calls himself "secure" still exposes so much unencrypted data, for so long, even when it is not actively used. I really hope you will wake-up in 2018, have a look at the solutions that are readily available in open-source and solve these issues. That's what open-source is for, take advantage of it. And I really hope you drop this idea of writing everything yourself in C/C++ to have full control of it. It is a waste of time and you will never be able to sustain a fast evolution pace if you have to manage all the code of Enpass yourself. Focus on what you are really good at, in my opinion usability and UX, and just borrow everything else from open-source, especially security because, obviously, it is really not your strength. Plus, since some of these open-source solutions are audited, you will have audited security for free.

I really hope you secure Enpass very soon because, when you're good, like in usability and UX in general, you are really good, the best in my opinion. Nobody can be the best at everything, and the reason people migrate to Enpass is, I think, more because you provide a better UX than others, rather than because you provide a better security (which you really don't, sadly).

For now, I will return to Keepass because Enpass is definitely not secure right now, but I'll keep watching you and wait until I can migrate back to Enpass. Crossing fingers.

Edited by Vincent
Edited "Hardware encryption" suggestion

Share this post


Link to post
Share on other sites

Hi @Vincent

Thanks a lot for your time and efforts for a delineated feedback. There is no point in getting offended by your post though I really appreciate that.

Security of data is the utmost priority for us and what I meant with my statement was that if the OS is compromised, there is less left for a password manager to protect the user's data from malware, key-loggers which can together steal both the master password and data. I also agree with you for having the maximum added protection.

The rewriting of the core is something which is required not only for the purpose of security (though this is the major reason) but also to add more functionalities with best possible UX to support multiple vaults and other most-in-demand features. By rewriting, I didn't mean ditching the used open source technologies rather I meant restructuring the architecture and the way of interaction between UI and SQLCipher.

The development of new core has already been done considering all the security aspects; memory encryption and storage in memory, and we are now working on implementing it across the platforms. I agree that the release has been delayed but we are on it. We have also considered Security Audit by third party and I assure that you will definitely like the improvements and the design. This is all I can say for now.

Cheers!

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×