Best option to store username and password in andr

Question

I am developing an app where user needs to sign in to perform operations...but mostly on android handset ppl use "keep me signed in"...and in tht case I'll have to maintain the value of username and password within my app..should I use preferences, or SQLite Db or is there something else and how can I make it secure? Plz Help... Thanks in advance..

Answer 1

 //encode password
 pass_word_et = (EditText) v.findViewById(R.id.password_et);
 String pwd = pass_word_et.getText().toString();
                byte[] data = new byte[0];
                try {
                    data = pwd.getBytes("UTF-8");
                } catch (UnsupportedEncodingException e) {
                    e.printStackTrace();
                }
                String base64 = Base64.encodeToString(data, Base64.DEFAULT);
                hbha_pref_helper.saveStringValue("pass_word", base64);

 //decode password
 String base64=hbha_pref_helper.getStringValue("pass_word");
            byte[] data = Base64.decode(base64, Base64.DEFAULT);
            String decrypt_pwd="";
            try {
                 decrypt_pwd = new String(data, "UTF-8");
            } catch (UnsupportedEncodingException e) {
                e.printStackTrace();
            }

Answer 2

As others have said there is no secure way to store a password in Android which protects the data fully. Hashing/encrypting the password is a great idea but all it will do is slow down the "cracker".

With that said, this is what I did:

1) I used this simplecryto.java class which takes a seed and a text and encrypts it. 2) I used SharedPreferences in private mode which protects the saved file in non-rooted devices. 3) The seed I used for simplecryto is an array of bytes which is a little bit harder to find by decompilers than a String.

My application was recently reviewed by a "white hat" security group hired by my company. They flagged this issue, and indicated I should be using OAUTH but they also listed it as a LOW risk issue, which means it's not great, but not bad enough to prevent release.

Remember that the "cracker" would need to have physical access to the device AND root it AND care enough to find the seed.

If you really care about security, don't have a "keep me logged in" option.

Answer 3

The safest way to do this without jeopardizing security is to use the shared preferences to store ONLY the username of the last person to login in.

Also, in your table of users, introduce a column that holds numeric boolean (1 or 0) to represent whether the person checked the person checked the "remember me" checkbox or not.

When launching your app get the username using the getSharedPreferences() function and use it to query your hosted database to see whether the signedin column is either 1 or 0 , where 1 indicates the person checked the "remember me" checkbox.

Answer 4

At the very least, store it in SharedPreferences (private mode) and don't forget to hash the password. Although this won't really make a difference with a malicious user (or rooted device), it's something.

Answer 5

Yes, this is tricky on Android. You don't want to store the plaintext password in the preferences, because anyone with a rooted device will basically be displaying their password to the world. On the flip side, you can't use an encrypted password, because you'd have to store your encryption/decryption key somewhere on the device, again susceptible to the root attack.

One solution I used a while back is to have the server generate a "ticket" which it passes back to the device, which is good for a certain period of time. This ticket is used by the device for all communication, using SSL of course so people can't steal your ticket. This way, the user authenticates their password on the server once, the server sends back an expiring ticket, and the password is never stored anywhere on the device.

Several three-legged authentication mechanisms, like OpenID, Facebook, even Google APIs, use this mechanism. The downsides are that every once in a while, when the ticket expires, the user needs to re-log in.

Ultimately, it depends on how secure you want your application to be. If this is simply to distinguish users, and no super-secret information is being stored like bank accounts or blood types, then perhaps saving the pwd in plaintext on the device is just fine :)

Good luck, whatever method you decide is best for your particular situation!

Edit: I should note that this technique transfers the responsibility of security to the server - you'll want to use salted hashes for password comparison on the server, an idea you'll see in some of the other comments for this question. This prevents the plaintext password from appearing anywhere except the EditText View on the device, the SSL communication to the server, and the server's RAM while it salts and hashes the password. It's never stored on disk, which is a Good Thing(tm).

Answer 6

Using NDK for encryption and decryption along with defining the String Key variable there instead of saving it in the shared preferences or defining it ins the string xml would help to prevent secret key stealing against most of the script kiddies. The resulted cipher text would be then stored in the shared preferences. This link may help about the sample code