I'm developing an Android APP to control a food safe which should be closed e.g. for 20hours. As I want to use it myself I want that the App creates a random password and stores it in the controller of the safe (Bluetooth + Arduino) and in the App. The safe only accepts commands from the phone if the password is correct.
How can I hide the password in the APP from myself?
I tryed to store the random password in the encrypted shared preferences, but I just need to connect my phone to my PC and run the APP and then I can debug the password (though it is a released non debuggable version).
Any advice would be so great. Thanks
I'm not sure about what's the issue you're facing.
About hiding the password from yourself the best way I found so far is saving the MD5 equivalent in a file/DB.
To login instead of doing (TextBoxPassword == Password) you will call a function: (GetMd5(TextBoxPassword) == Password), where the stored password is already an MD5 hash.
Related
Is there a way to lock every app i give to the end user with a unique password so that only i can generate a valid password to unlock that app and a copy of that app should not unlock with same password aswell.
I don't wanna setup online server for that. I need my app to be unlocked offline.
You can generate password on a first Application start using current time of system and Android Id, for example. Then you should show to user this time (that can be shown to them in some non-readable format) and his Android id. Then user sends you (or reads by phone, etc), this two lines and you combine them in a password using the same algorithm as phone did.
If the password can be long - create md5 hash of string, consisting of needed data. If it should be short - decrease the length of md5 or make some algorithm that will take only needed length from the whole password.
I build an Android Application, that needs some password and some Identiy information, for tests I just put them in String variables, Now I am looking for a way to Encrypt them, Any ideas ( Without Hash code ).
Thanks for your responses.
AccountManager can helps you to store in a secure place, username and password of your application:
https://developer.android.com/reference/android/accounts/AccountManager.html
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.
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.