Comments (8)
From [email protected] 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: [email protected]
Labels: -Type-Defect Type-Enhancement
from cryptonite.
From [email protected] 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
from cryptonite.
From [email protected] 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.
from cryptonite.
From [email protected] 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.
from cryptonite.
From [email protected] on June 09, 2012 06:20:15
Summary: Store passwords
from cryptonite.
From [email protected] 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.
from cryptonite.
From [email protected] 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.
from cryptonite.
From [email protected] 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!
from cryptonite.
Related Issues (20)
- It doesn't work on Android 6, isn't it? HOT 1
- truecrypt PIE HOT 3
- android 6 mounting visibility issue HOT 6
- Not compatible with Windows EncFS apps HOT 2
- Mounting fails without error message HOT 1
- Contribute cryptonite to f-droid HOT 5
- OSX fuse usage HOT 5
- Mount dropsynch - synched folder as volume?
- New instructions HOT 3
- Binaries for Intel x86/x64
- How do I mount TrueCrypt'd Flashdrive? HOT 1
- Truecrypt - Error: Cannot convert from the charset 'encoding - 1' HOT 4
- Getting error when attempting to open files
- Create volume on external storage? HOT 2
- New Maintainer(s) Needed?
- Error in building encfs on Ubuntu 16.04 HOT 2
- Dropbox API v1 shutdown, sync not work HOT 1
- Mount failed on a Lenovo rooted device running with lollipop 5.1.
- Lineage Oreo 8.1: Mounts ok, but the mounted folder is empty
- Is cryptonite still active? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cryptonite.