Store passwords

[GoogleCodeExporter]

This is meant as a feature request ;-)

Some have already asked for multiple mounts or on-boot mounts.

I'd appreciate an editable list of different mounts with an option to select to 
mount an entry manually, on boot or on access. And of course all the passwords 
should be stored without the need to re-enter them ;-)

Great work so far,
Sebastian

Original issue reported on code.google.com by piecha...@gmail.com on 8 Jun 2012 at 8:23

[GoogleCodeExporter]

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

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Original comment by christoph.schmidthieber@gmail.com on 9 Jun 2012 at 1:20

• Changed title: Store passwords

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Moved