Store passwords

[neurodroid]

From piecha...@gmail.com on June 08, 2012 21:23:46

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: http://code.google.com/p/cryptonite/issues/detail?id=29

[neurodroid]

From christoph.schmidthieber@gmail.com on June 09, 2012 02:45:29

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?

Status: Accepted
Owner: christoph.schmidthieber@gmail.com
Labels: -Type-Defect Type-Enhancement

[neurodroid]

From christoph.schmidthieber@gmail.com on June 09, 2012 02:46:54

Sources: [1] http://throwingfire.com/storing-passwords-securely/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+throwingfire+%28Throwing+Fire%29#notpasswordhashes [2] http://stackoverflow.com/questions/7626914/using-jbcrypt-to-salt-passwords-in-android-app-causes-a-long-hang

[neurodroid]

From piecha...@gmail.com on June 09, 2012 05:36:35

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.

[neurodroid]

From christoph.schmidthieber@gmail.com on June 09, 2012 06:19:59

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.

[neurodroid]

From christoph.schmidthieber@gmail.com on June 09, 2012 06:20:15

Summary: Store passwords

[neurodroid]

From piecha...@gmail.com on June 09, 2012 06:30:07

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.

[neurodroid]

From piecha...@gmail.com on June 09, 2012 06:41:15

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.

[neurodroid]

From ari...@gmail.com on August 23, 2012 13:09:20

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!