Jump to content
Enpass Discussion Forum

Recommended Posts

Guest Akash Vyas
Posted

Hey guys,

We know you've been waiting for this to happen for a long time and we really appreciate your patience.  We're hoping to roll it out by the end of this year but there came some situations with urgent improvements in Enpass 5;  like Firefox WebExtensions, Edge extension etc, so we had to take care of them, curtailing time for it from the development.:S However, our dev team is back on it and working really hard to keep up the pace and get features implemented. We'll keep you updated.

Thanks for your understanding.      

  • 1 month later...
Posted

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

Guest Akash Vyas
Posted

Hey @wachschaf

Thanks for stopping by and sharing your concern. 

I think the following post addresses your concerns:

Cheers!

Posted

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

Posted (edited)

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
Posted

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!

Posted

Well, today is January 22, 2018, it's been a year since you promised a third party audit. Where is Enpass 6?

I hope we can see the progress of your work as this is a top concern for our users. It relates to whether we can trust enpass or not.

  • Like 1
Posted

no 1pw is not open source as far as i remember.

also I have no exact idea when 1pw6 was released but the version before had a drastically different UI.

Posted
21 hours ago, My1 said:

no 1pw is not open source as far as i remember.

also I have no exact idea when 1pw6 was released but the version before had a drastically different UI.

"drastically different UI"

v5 v4 v3

Posted (edited)

the UI I saw was more like this:

385059-agilebits-1password-4-for-windows

and reminds me more of keepass.

and having a list of categories on the left and on the middle the list of entries and the content on the right (or bottom) isnt really creative, this is a similar thing as what mail clients can do for eternities, and this basic idea which makes sense, it's not really a wonder they look similar.

Edited by My1
Posted
On 2/4/2018 at 6:26 PM, My1 said:

the UI I saw was more like this:

385059-agilebits-1password-4-for-windows

and reminds me more of keepass.

and having a list of categories on the left and on the middle the list of entries and the content on the right (or bottom) isnt really creative, this is a similar thing as what mail clients can do for eternities, and this basic idea which makes sense, it's not really a wonder they look similar.

I don't know how it looked on windows. On mac it was different. But it is offtopic here. So what about security audit?

  • 4 weeks later...
Posted
On 2/2/2018 at 2:35 AM, loginx said:

Any update on this? I can't trust a closed source proprietary software with no audit. You guys shamelessly stole 1password's ui, please provide us some proof.

I agree that there is a strong resemblance between the Mac version UI of 1PW and enpass but 'shamelessly stole' are some strong words to use here.
The UI for enpass may not have any unique creativity but it isn't possible to drastically differentiate every app from all the other apps having similar functions. Some designs may be proven to be aesthetically and functionally fulfilling all goals and drawing ideas from them, while avoiding blatant plagiarism, is nothing bad at all.

 

On the main topic, I am truly disappointed that an otherwise excellent app, is dragging its feet so badly on being open for a security audit. After all, it is not trivial data that they are dealing with. These little things are what could turn away potential customers or deter evangelists from referring users to it.

Posted

I commented here approximately 1 year ago. Due to the silence from the developer, I am unfollowing this thread and will continue to recommend Lastpass to everyone who needs a password vault. 

Posted
6 hours ago, mudfly said:

I commented here approximately 1 year ago. Due to the silence from the developer, I am unfollowing this thread and will continue to recommend Lastpass to everyone who needs a password vault. 

has Lastpass been Audited?

also Lastpass obviously has the problem that they have your data. also the way LP stores the data is apparently relatively open and based on standards so people can try to check that for themselves.

Posted
16 hours ago, My1 said:

has Lastpass been Audited?

also Lastpass obviously has the problem that they have your data. also the way LP stores the data is apparently relatively open and based on standards so people can try to check that for themselves.

Lastpass is not without its own set of issues, I am not sure about an independent third party audit of Lastpass. What I do know, is that they are an American company, and I am American, and so if there is an issue I can hire a lawyer, or join a class action if the need arises. I also work for one of the largest software companies in the world, who as a saas company, we take security very seriously. We use a corporate Lastpass to manage our shared secrets. If my company with their secrets trust Lastpass, who am I to disagree with their independent security audit? I requested my account be deleted, so I don't know if you will see this reply. All of my posts will be removed when my account is removed.

Posted

okay, well I am not from the US and therefore essentially both LP and Enpass are alien companies for that matter. one of the best things about enpass is that they make it easy to not need to trust them. their database is in a relatively open format and I can choose where to store, or even do the sync myself while letting enpass itself not even touch the internet with a "10 foot pole" as you americans tend to say (I'd rather say ten meter, but that's another story).

 

meaning I could essentially pseudo-aigap Enpass and let for example the Nextcloud client do the sync of everything, which makes it impossible for Enpass to doanything crazy in regards to move data somewhere where it doesnt belong or whatever.

 

regarding seeing your replies, I have an email notif, but even if I hadnt, usually when an account is removed the posts dont vanish and it will mostly remove your picture and other data and say deleted user instead of your username.

Posted

Created an account to say that I'm glad I've held out paying for Enpass mobile for so long. I've used it on my desktop, synced to my encrypted drive, and while I do generally trust that the developers have good intentions in terms of security, I can't put my trust in a company that's been promising a security audit for so long (as well as the next version of Enpass for even longer!)

Switching for now. Good luck Enpass team!

  • Like 1
Posted

Hey guys,

We understand that security audit of Enpass has grown significant mass and holds the first priority for all of us. The frequency of comments on this post has become an occasional topic of conversation here pushing us to deliver the beta of Enpass 6 as soon as possible. 

As I mentioned previously, the best way to audit Enpass would be for the new architecture only because doing it for the current version shall all be in vain. No excuse that we are late in releasing the Enpass 6 but that was due to some unavoidable issues and feature updates.

10 hours ago, wepebavum said:

Switching for now. Good luck Enpass team!

Your best wishes for good luck are what we need always but nothing is more painful than parting from you. All I can say at the moment is to please wait for some more time as the New avatar of Enpass is on the way

Thanks a lot for your understanding!

  • 4 weeks later...
Posted

I'm just starting out with Enpass and I love it! But i just would like to note that I'm also very concerned with this issue! 

I can only fully trust my personal data to Enpass and recommend it to others if it's Open Source and / or Audited by a qualified and trusted external organisation. 

  • Like 1
Posted

I am concerned about this issue too! And gonna switch to another solution.

I'll switch back to Enpass and pay a license the day you publish an audit result.

  • Like 1
Posted

Dear Team,

Concerned user here as well switching back to another solution untill the day you publish audit results

Please make it happen! Because I like the software, but at this point I hesitate filling in any sensitive data.. Worried about backdoors and such.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...