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.
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.
Please I have the following scenario:
the app uses a password to access to some remote webservice over HTTPS;
to do so, the app asks the user the password, does NOT store it on the device (and use it in a safe manner to access the webservice).
My concern is the following: it's theroetically possible to access the memory to read the data it contains and eventually retrieve the password.
Please how do I prevent this from happening?
Thanks
Please how do I prevent this from happening?
I wear tin-foil hats on a professional basis (besides, I think they look spiffy...), and this is beyond what I normally worry about. I'd worry about making your HTTPS code won't be the victim of a Martian-in-the-middle (MITM) attack, as that's a lot easier for an attacker to execute.
That being said, as samgak alludes to in a comment, String is immutable. Once the password is in a String, you are at risk for the attack that you describe.
If you use an EditText to collect the password, do not call getText().toString() to get what the user typed in. getText() will return an Editable, which allows you to get at characters, not a String. Then, if your HTTP client API allows you to fill in the password using a char[], once the HTTP request is done, you can clear out the contents of the char[], clear() the Editable, and then pray that EditText and kin aren't holding onto a String anywhere that represents what the user typed in. This may vary somewhat by device, as device manufacturers have had a long history of screwing around with EditText behavior, and so what may be clean in terms of AOSP code may be less clean on the hardware from some certain manufacturers.
If you are getting the password by some other means (e.g., your own set of PIN entry buttons), just avoid a String representation of the result, and wipe out the char[] when you're done with it.
Yes, theoretically it is possible, when having physical access to the device. At least it possible to debug the application and to catch a value in any point when encoded/decoded, i.e. it is open.
But much more simple way it is to catch user input itself, when he enters a password. So, you not need to worry about memory sploits.
Ok, I'm stuck with this problem. I want the "administrator" to be able to add points to a users account. What I want to happen is the administrator has to enter a password to be able to award points to the user. I know that this will have to be in popup format, but I'm just not sure how to do that. So basically my question is: How do I password protect a certain Activity inside of a class?
There is no functionality that will this automatically. You can write manual code for a dialog to pop up, accept a password, have an AsyncTask that will verify that password against your server, then add the points or re-route to the desired activity.
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.
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.