Closed GoogleCodeExporter closed 9 years ago
Thanks for the suggestions.
Multiple mounts: See issue #11
On-boot mounting: See issue #14
List of volumes: See issue #22
Password storage: That's difficult to say the least. Of course it wouldn't be a
problem to store an MD5 password hash. However, using a _secure_ password hash
function [1] might be prohibitively slow on most Android devices [2] if I'm not
mistaken. Suggestions are welcome.
Can we change the topic of this issue to "store passwords" and discuss the
other suggestions in the corresponding issues?
Original comment by christoph.schmidthieber@gmail.com
on 9 Jun 2012 at 9:45
Sources:
[1]
http://throwingfire.com/storing-passwords-securely/?utm_source=feedburner&utm_me
dium=feed&utm_campaign=Feed%3A+throwingfire+%28Throwing+Fire%29#notpasswordhashe
s
[2]
http://stackoverflow.com/questions/7626914/using-jbcrypt-to-salt-passwords-in-an
droid-app-causes-a-long-hang
Original comment by christoph.schmidthieber@gmail.com
on 9 Jun 2012 at 9:46
Good idea to change this topic to "store passwords" and address every thing
else in the other issues.
Just some thoughts for storing passwords:
Despite a secure algorithm to store passwords we would need some major password
to decode them. What do we do then with this major password? Enter it manually?
Then automatic mounts won't help.
I'd suggest a different approach. For those who just wan't to secure data
stored locally in the phone the only feasible approach would be to enter the
password manually - no need to store these passwords then, even not encrypted.
For those who want to secure some cloud service (like I do) they could store
their cloud password (which of course is a different one than every other
password they use ;-) even unencrypted on their phone. What's the risk? Their
smartphone might get lost or some malware could eavesdrop their password. The
former is even a risk if we store the passwords encrypted and allow automatic
mounts, but we can immediately block access to the cloud service if the phone
gets lost so the data remains safe. So that's just a little risk then. The
latter (malware eavesdrop the phone) again doesn't make a huge difference if we
use different passwords for different services - just the one cloud service
password gets lost. If we care about the data there's again no difference if we
store the password encrypted or in plain text. If malware gets introduced on
the phone and we allow automatic mounts (which I want) then the malware could
eavesdrop the data although the password might be encrypted - in that case just
the password might stay undetected (which I again just don't care of as I use
different passwords for every service).
I want to secure the data while being stored in the cloud then the only
requirement is to not store the password in the cloud as well. If looking at
the risks then there is only little difference if we store passwords encrypted
or in plain text locally.
Original comment by piecha...@gmail.com
on 9 Jun 2012 at 12:36
While it might not make a difference for a lot of users whether the master
password for online EncFS volumes is encrypted at all because it's just about
security on the server side (which doesn't get to see the password), this
certainly doesn't apply to all users. It's especially problematic because
people tend to re-use passwords or parts of passwords a lot, and a lot of users
maintain local copies of their online volumes with Dropsync or similar apps
which would then be vulnerable. Lengthy warning messages are not an option
either.
Original comment by christoph.schmidthieber@gmail.com
on 9 Jun 2012 at 1:19
Original comment by christoph.schmidthieber@gmail.com
on 9 Jun 2012 at 1:20
That's true but in the case they need to secure the data stored locally on the
phone a device pin might be a solution. And they shouldn't be mounting
encrypted folders automatically without entering a password then as this would
circumvent the security of their data (despite the fact the password is
encrypted or not).
To sum it up - users who want to secure their local data must enter the
password manually on mounting an encrypted folder. In that case they could use
(and remember) one password for all their local folders. No need to store this
password then.
All other users who want to secure cloud folders could store their passwords
even unencrypted on their devices.
Original comment by piecha...@gmail.com
on 9 Jun 2012 at 1:30
Forgot to mention why I wrote these thoughts: I think a quick solution would be
to implement the password storage without encryption and just remind the users
how to use this feature while accessing locally/cloud stored data. As soon a
good solution for encrypting passwords emerges this could be used instead.
Original comment by piecha...@gmail.com
on 9 Jun 2012 at 1:41
Please add the option to store passwords on the device, you can display a big
warning about how insecure it is, or even bury that option deep in the
settings, but it would definitely be very useful in some cases for people who
know what they are doing.
Thanks!
Original comment by ari...@gmail.com
on 23 Aug 2012 at 8:09
This issue has moved to https://github.com/neurodroid/cryptonite/issues/29
Original comment by christoph.schmidthieber@gmail.com
on 28 Aug 2014 at 3:55
Original issue reported on code.google.com by
piecha...@gmail.com
on 8 Jun 2012 at 8:23