Ongoing Development?
cryptono opened this issue ยท 22 comments
Hi,
I am a new user and change from KeePassX to Encryptr now.
The last commit and activity is some time ago, is it still developed and maintained?
Encryptr is unique on password manager market, I would love to see you expand the dev activities. :-) There are many missing features!
At this point, the total radio silence and lack of commits (both here and for Crypton) seems to imply that SpiderOak isn't interested in developing this anymore, or is perhaps is looking to continue development on it privately.
Either way, it would be a good opportunity to see if anyone is interested in a community fork for either project (especially anyone who's good with node and NW.js!). I've been running a local instance of Encryptr/Crypton for a while and really like it, but you're right that there are definitely some features missing that prevent people from switching and using it as a go-to password manager (especially organization, import/export).
I'd love to help with a community fork if we can find some node hackers to participate ๐
@4oo4 I really like that idea. But it is probably hard to find someone with time and node experience, I personally can't participate unfortunately. Still hope that you find someone. ๐
@cryptono what made you switch from KeePassX? and have you checked out the community fork of KeePassX called KeePassXC? https://keepassxc.org/
I'm looking to do the opposite of you and switch to KeePassX because of the Android Clipboard security issue that Encryptr has not fixed yet (for their Android app).
They have an issue open for it but nothing has been done yet: #101
You can read more about this critical issue here: https://news.ycombinator.com/item?id=13460843
@FranciscoG yeah, I really like keepassxc. But auto login isn't really well implemented so far. I really don't want to think about my passwords. As LastPass announced to offer cross platform as free option. So I switched to LastPass (not entirely so far) and love the auto login feature. I would prefer keepassxc, but the browser integration is buggy...
@cryptono ah ok. Those are all things I definitely don't want. With convenience comes more points of failure and insecurity, especially since I'm on Android.
Recently LastPass and a bunch other Android password manager apps were found to have vulnerabilities: https://team-sik.org/trent_portfolio/password-manager-apps/
Security Now podcast covered this: https://media.grc.com/sn/sn-602.mp3
starts at about 37min into it
note: all vulnerabilities mentioned in the article have been fixed. I mention this as an example of how these apps tried to make something easier for the user and ended up making their apps vulnerable. Sure they are all fixed now, but who knows what else is vulnerable in their apps, or what future features of convenience will end up being vulnerable.
from the podcast:
"We found several implementation flaws resulting in serious security vulnerabilities. Some applications stored the entered master password in plaintext, or implemented hard-coded crypto keys in the program code. Consequently, attackers can easily" - now, that's a little questionable because I looked at this carefully also. But they say "attackers can easily circumvent the crypto algorithm" - so I would say "can" circumvent the crypto algorithm - "altogether and thereby gain access to all of the user's data. In other cases, we could simply access all 'securely protected passwords and credentials' with the help of an additional app. Once installed on the device, this malicious app extracts all passwords and credentials in plaintext and sends them to the attacker.
"In yet another case, we could use a so-called data residue attack to access the master key of an application. In most of the cases, no root permissions were required for a successful attack that gave us access to sensitive information such as the aforementioned master password. Furthermore, many of the apps completely ignore the problem of clipboard sniffing, meaning that there is no cleanup of the clipboard after credentials have been copied into it.
"While this shows that even the most basic functions of a password manager are often vulnerable, these apps also provide additional features which can, again, affect security. We found that, for example, auto-fill functions for applications could be abused to steal the stored secrets of the password manager" - and we've been talking about form auto-fill hacks and attacks in the last couple podcasts - "using hidden phishing attacks."
...
In the case of LastPass, which I was most curious about, they write: "The Android app of LastPass comes with an access control mechanism which prohibits arbitrary usage of its functionality. By default, the user is asked to enter his master password in order to gain access to the application. Due to its enforced complex requirements" - meaning LastPass Android requires a complex master password - "a user can easily get frustrated entering the master password over and over again. Therefore, LastPass offers to substitute the master password with a PIN mechanism." So here, again, we're trading security for convenience. "Thereby the user can agree to save the master password on the device" - because remember, the master password is what decrypts the store, that is, the storage blob, so you still need the master password somewhere.
So LastPass offers to substitute the master password for a PIN. "Thereby the user can agree to save the master password on the device and shift all access control to a PIN, which can be from 4 to 14 digits long. The master key and the PIN are symmetrically encrypted and stored in a shared preferences file in the local app folder. The key and PIN are stored encrypted. The key for encrypting and decrypting the credentials is hard-coded into the application's source code." Thus the problem, and that's what LastPass - that's what these guys found. And LastPass said, okay, you're right, we could do better. So the key for encrypting and decrypting the credentials was found to be hard-coded into the application's source code.
However, even so, for stealing the encrypted master key or PIN, we assume, and that is they required, that the attacker gained physical access to the device, which we're now calling the Evil Maid attack, and in which case that approach required reading out the LPAndroid.xml content, which did not require a root exploit. But not on each Android version. So only on some was this possible. The second approach did require a root exploit, which exists for various types of Androids, depending upon version.
@FranciscoG Arw, your damn right, with every single point. To be honest: I don't know what to use anymore. There are many problems with all password managers and even in general with passwords. I am conviced that it is a desaster that we have to think about passwords in 21. century. We need a new solution - or maybe just a open source, cross plattform password manager with auto type, balancing between security and comfort. :-) This requires to find active people who program for community, and as we see, this is not very easy (e.g. Keepass or Encryptr) :/
I actually dropped Encryptr for the reason of discontinued development. After some research, I can recommend KeeWeb. It actually has many of the missing features from Encryptr. However, auto fill-ins are not possible as of my knowledge. You can access it from your browser or via web-login (if you have the database saved encrypted in a cloud.
@elDan101 Thanks for the tip. It seems to be a real solid worth seeing alternative to Encryptr. Hope there will be a auto type or login feature in the future. :)
We are planning a major update to Encryptr later this year.
Source: SpiderOak 17/05/2017
agree with most of the above - I have found various password mgrs lacking on security or crucial features. my experience with spideroak made me hope that encryptr would be the solution - I would gladly pay a one time fee to use it. it doesn't have to be free for me, but it does have to be: open source, secure, simple to use, cross device linux desktop / android mobile, a working auto save function w.o. copy/paste when filling out new forms.
too much to ask?
I suggest open a crowdfunding project to commit user group to developer group.
Agree with @chthonics
I don't know how the infrastructure works in terms of if it is hosted on SpiderOaks' cloud so I'm not sure about the cost.
Can we get this on www.gratipay.com to fund development?
I'd certainly pay money to fund ongoing development on this
I understand that development is currently stalled and a new update in planned for some time this year.
But why haven't the pending PRs been committed? I see that one in particular (#289) seems to address a lot of the missing features mentioned on this thread, and even has a corresponding PR in Crypton that's also waiting to be committed since June (#448).
Are there any plans to commit these PRs or has development put completely on hold?
Cheers
Sorry to insist, but can a dev please let us know what the plans are?
Are the PRs I mentioned going to be committed or are we better off forking and starting our derivative project?
Thanks,
Peter
I am pretty sure the current PRs have been merged and are just awaiting release by SpiderOak.
my understanding on encryptr at this time is that it will no longer receive support or updates - a few weeks back I submitted a support ticket to spideroak because my android side of encryptr froze up and has not changed despite removal/reinstall.
the reply I received was that the actual secure design of the app made it difficult to impossible to address any issues. due to this fact spideroak is not providing any resources to the project and either will discontinue it completely or replace it at some point with a completely different product.
that was the email reply I received from spideroak support. since I depend on having access to passwords both on linux desktop and android phone I am moving to enpass as solution for myself. unfortunately
https://bitwarden.com/ seems a valid alternative.
Thanks @devgeeks
Indeed the PRs seem to have been merged these last couple of weeks.
But that applies only to encryptr. Any idea why the corresponding PRs on Crypton are still waiting to be merged? https://github.com/SpiderOak/crypton/pull/448
There seems no point in compiling encryptr if the backend is still not compatible with the updates.
As I mentioned in the linked issue, my understanding is that Crypton is not being maintained going forward. Any updates to Crypton would only be to support features they might add to Encryptr.
Thanks @devgeeks
I replied in the crypton issue thread, but basically I understand what you're saying and it makes sense.
But in this particular case, I see the new offline/backup features PR was merged into Encryptr but the corresponding Crypton side PRs haven't been merged yet. So the latest Encryptr available on github won't work with the current git available on Crypton (until the PRs are merged). Is this correct or will the current Encryptr client (with new features) actually work fine with current Crypton code?
Cheers,
Peter