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
Related
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.
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 have a simple RESTful backend and I am using HTTP Basic over HTTPS for authentication. It works fine, but I am looking for a appropriate solution to store the credentials (username + password).
There are a lot of examples out there and the majority suggest to use the Account Manager to store passwords. AFAIK the account manager stores only OAUTH (and similar) accounts and automatically generates tokens etc. But how can I use it to store and fetch the original passwords? Is it even possible?
Others suggest to store it as a hashed value, but this doesn't make sense to me (At the end of the day I will need to have access to the original string).
Sorry for another How to use HTTP basic and android question, but I was not able to find a suitable answer so far and to store the data within the local sqlite db as plaintext doesn't seem to be appropriate.
I have a few thoughts concerning your project/style of usrmanagement.
Why do you want to save the password on the device?
Why don't you work with auth tokens
Why not workig with the good old sharedPreferences.
I would suggest to do it like this.
At first register(no password and username are neccessary, it creates a user "Guest123") or login to the server with a password (hashed by the device, getting from a normal edittext from the user).
Then check for correctness on the server, if valid, send back an auth token and a time to live for that token.
Store this in the sharedpreferences.
Send the token with every request you make to the server, if this token is not valid (because time is over, logged in on another device...), tell the user.
There are couple of tweaks which could be done here, but for the beginning it shoul help ou on your project.
Of course you can use the Account Manager to store password as well. This is the method:
addAccountExplicitly (Account account, String password, Bundle userdata)
and you can get the password using this method:
getPassword(Account account)
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 don't want to publish my app on Android Market, but i would create a license key from my website based on the MAC address of the user device. It should include also expiration date.
Once the user enters the code in the android device it should be recognised.
I've read that it can be done by using custom public encryption. In this scenario i should implement:
A function in my application that takes the MAC address of the
device and shows a string to the user.
A function on my website that owns the private key and cipher the string at point 1. and adds expiration date
A function in my application that decipher the string at point 2. using the puplic key and validates the license key.
I've read many discussions on stackoverflow and other sites but nothing applicable... or it is not clear how to apply in my scenario :(
Can you provide me e way to solve this problem? is there something that is android native that i'm missing (i hope) ?
Many thanks!
Marco
I see nothing really difficult to implement your intents:
Your licensing server must have its own private and public key pairs.
Then you have to create private key in your application during 1st run/install. It can be done just randomly
Then you have to interchange between your application and server with public keys
During buying/licensing procedure your application should encrypt MAC address or other (gmail id, IMEI code whatever) send to server - server stores key
In order to check validity of license application sends to server cipher of MAC - server checks it against stored in database
If you don't know how to implement private/public keys stuff - read manuals, there're a lot of implementations of Diffie-Hellman's procedure - it's easy and nothing special there
I was looking to implement licensing on apps that are not distributed through Play and came across this:
https://code.google.com/p/droidactivator/
Maybe it will help you too?