I want to lock my application with a password which the user has set in the applications settings.
Each time the main acitivity of my app is going to be shown, a password dialog should be shown instead. I know how to do that, but i wonder... :
How do I store the password the user has set? I can't store it in SharedPreferences because you can delete SharedPreferences in your phone's settings. I thought about a textfile which holds the password, but this file can be deleted, cant it?
Any ideas?
You cannot protect against the password being deleted one way or another, so you need to step back and consider why you have a password in the first place. Most likely you're using the password to protect data the app has access to, rather than the actual app itself (since protecting the app from running is not going to be effective against an attacker that has physical access to the device.
If your password is to protect data, you only need to ensure that an attacker cannot access the data due to deleting a password store. One way to do this is to use the password as an encryption key (or part of a key) that obscures the data -- thus there's not even a password to delete.
One option is to put the password in the same file as where you have the other information (I reckon you want to protect the settings/data of the user). Just do not start the app when that file is missing or corrupted. What you have accomplished then, is that the information is rendered unusable if someone tampers with the data. Sign / encrypt your data file(s).
Another solution could be to store the password (hash!) on a webserver.
Related
I have an app which allows to remotely lock other phones named "Parental Lock".
In the app, users can put a password for a time to their "children"s phone.
The problem is when the time specified by the "parent" ends, I want to remove the password given by the "parent" and restore the original one if there was.
For now, when the time ends, I am removing the password via device manager from the phone but to restore the old password put by the user itself long before, I must get the password info.
The get the password, the password itself had to be encrypted in first place (with yet another password, brr).
And the rule #1 says: never ever encrypt passwords, use hashing algorithms with a salt to store them.
I'm creating an android app which requires a login process. My issue is with implementing a "remember me" function in the app. There are several questions surrounding this issue already on the internet, but I was wondering if there is an easier way than creating public keys for the app or using OAuth (disclaimer: novice developer).
I read the existing questions like How do I implement a 'Remember me' function in an Android Activity? and Security: How should I store ("Remember") a user's username and password for future use? but they suggest two methods of password storage: plaintext in SharedPreferences, or hashed in SharedPreferences. However, the answers go on to say that these can be compromised if someone has access to the phone.
As a preliminary question, I would ask whether it is necessary to maintain security once someone has root access to the device/the hashed password, considering that cracking the password may give the intruder access to other accounts the user has made. If so, would it be beneficial to implement a system which performs this function but without ever storing the user's password (plaintext or hashed) on the phone.
I was thinking of a method which works using three steps:
When a user successfully logs in AND has checked the "remember me" checkbox, store their username in a SharedPreferences file.
Store a boolean value in the database indicating whether the user has checked the "remember me" box.
When the app starts in future, it automatically checks the SharedPreferences file for a username. If a username is found, and the database value for that username is true, the user is logged into the app under that user name.
This way, the user's password is never stored on the app (either in cleartext or in hashed form). Would this be a secure way of implementing the "remember me" function, or should I use another method?
Apologies if this question is not specific enough/too open-ended.
As you do not store password in phone I think it's a secured way of implementing a "Remember Me" function. But, In your 3rd step you haven't mentioned how you will get the username to compare with the SharedPreferences. If users have to provide the username again it won't be a good method.
I just noticed this article about a mobile app that is storing user information in plaintext. I've paid attention to the idea of storing the user's password on the server (using a SHA-512 hash function), but I'm not clear on the best methods for storage of personal information at the device itself.
Let me be clear I am essentially only talking about user names and passwords. The data that my app interacts with is not at all sensitive, and I know that I can implement some sort of symmetric encryption/decryption on that data.
For user convenience purposes, I'd like to offer the user an option to store their user name and password locally so that they aren't required to enter it each time they use the app. But I know that user's tend to reuse the same password for many different purposes, which means that I need to take precautions to keep my user's passwords secure. Classic tension between convenience and security.
Is it just simply a terrible idea to ever store this information locally? Or are there relatively simple means to securely encrypt this? Do the iOS and Android O/S provide any help with this?
Not necessarily looking for exhaustive answers, but I'd really appreciate some topics to research, article links, books, etc. Thank you very much. If this is a redundant question, please direct me to any posts that give answers that are still considered current.
Thank you very much!
All data on the device is automatically encrypted by the device to some degree, using the device id as the key. This prevents data from easily being read by anything other than the device itself, or someone with the device id anyway.
There's another level of encryption that you can pile on that utilizes the passcode, called Data Protection, which prevents the data being read unless the passcode is entered.
You can manually enable data protection in your app by using NSFileManager to access files and setting the NSFileProtectionKey attribute to NSFileProtectionComplete. See: Implementing and Testing iOS data protection.
Note that the user must set their device to require a passcode, and the stronger the passcode, the more secure the data will be.
You may be able to easily enable data protection through the provisioning profile for your app, even if you don't use the NSFileManager class with NSFileProtectionComplete. See: Data Protection / NSFileProtectionComplete - successfully supported through entitlements.plist?
I still wouldn't store the password. Store a randomly generated session key that is created when they log in. At least you can expire those and it's not the plain text password.
Just a follow up to this post from a year ago. What I decided to do was to generate a random session key (similar to #Marcus Adams suggestion) but use that value as a salt. I then concatenate that session key with the user's chosen plaintext password and store this value on the device (if the user elects to store their password). i.e, the device stores this value:
device_hash = sha256(device_salt || plaintext)
That hashed value then becomes the string that I pass over HTTP to the server for validation. On the server side, I have a different salt value stored over there. When the server receives the device hash value, it has its own salt value which it concatenates to that string, and then performs its own hash. That final hash is the password that is stored in the server database. i.e., the server stores this string:
server_hash = sha256(server_salt || device_hash))
I think that this is a viable balance between security and convenience, particularly since I am only trying to protect the password, and not trying to encrypt the actual data that gets exchanged in the normal course of the app. If the user's device is compromised, no attacker can use a rainbow table or anything like that to reverse engineer the password since it is salted. SHA256 along with the long length of the password should eliminate a brute force attack if someone were truly motivated.
Curious if anyone has any criticisms of this approach.
In Android Device Administration, I know resetPassword(String password, int flags) can reset the password. But, my wish is that I will hold old password before reseting it. In this way, I can, if user wants, rescue the password. Are there a way to hold the password ? Moreover, how can I get password from system ?
NOTE: My application is system app.
No, you cannot get the password. It is indeed hashed, and the device technically doesn't 'know' it. Additionally, since pretty much any app can become a system administrator (if the user confirms), any app would be able to retrieve the password, which is a bad idea.
I'm trying to build an app with a login module. I want to save the user login state so that the end-user will not have to retype his/her credentials except if they have explicitly logged out.
I understand that SharedPreferences can be of some use but I would appreciate it if some one can provide me some of their expert insight in this matter.
use the below link.There is 3 way to store you login details . one is using shared preference and 2nd one way is store in a file and the third one is using sqlite. This will give you the ideas for storing login details.
save user data
You can use any of the three methods that Asish AP references. But for a small amount of data (one user's username, password, login state) SharedPreferences is probably the lightest / easiest.
But whichever way you go, you should make sure that you encrypt whatever you store using one of the Java encryption methods at Encrypt Password in Configuration Files?. Having plaintext credentials sitting around (eg on the SD card) is just way too vulnerable.