Jump to content
Enpass Discussion Forum

Vincent

Members
  • Posts

    2
  • Joined

  • Last visited

Posts posted by Vincent

  1. 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.

  2. I don't know if password versioning actually qualifies as "Security" but it would definitely be a security for the all thumbs users we sometimes are.

    Password versioning would keep old passwords in case, on an all thumbs day, we copy something irrelevant in the password field, or if changing our password on an account fails and we still need our old password. Like file versioning, it would be configurable in number of versions kept, and/or in age of old versions. It would be combined with a recycle bin if we delete an entry by accident.

    From a security point of view, I don't believe password versioning poses any risk otherwise a password manager like Keepass wouldn't have implemented it (They are very serious about security, like you are, although Enpass is much more practical in my opinion). For the most paranoid amongst us, password versioning and the recycle bin would be optional, but I would suggest to make it a option selected by default.

    Also, password versioning and a recycle bin are fairly easy to implement. I hope we will see it soon in a future version. I sorely miss it since I migrated to Enpass.

     

×
×
  • Create New...