Best option to store username and password in android app

Question

I am developing an Android app where the user needs to sign in to perform operations. But mostly on an android handset, people use "Keep me signed in", In that case, I'll have to maintain the value of Username and Password within my app. Should I use SharedPreferences, or SQLite Database or is there something else which I can use.
And how can I make it secure?

Solution 1

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-login.

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™.

Solution 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.

Solution 3

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.

Solution 4

You could use EncryptedSharedPreferences from the Jetpack security library. It works great for key-value type settings.

It wraps SharedPreferences, providing secure encryption/decryption while maintaining the same API as SharedPreferences.

As in their example:

  String masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC);

  SharedPreferences sharedPreferences = EncryptedSharedPreferences.create(
      "secret_shared_prefs",
      masterKeyAlias,
      context,
      EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
      EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
  );

  // use the shared preferences and editor as you normally would
  SharedPreferences.Editor editor = sharedPreferences.edit();

Solution 5

I wanted to save the password in the SharedPreferences , so I implemented it privately first like the code below

public class PrefManager {

  private SharedPreferences pref;
  private SharedPreferences.Editor editor;

  public PrefManager(Context context) {
    pref = context.getSharedPreferences("PROJECT_NAME", Context.MODE_PRIVATE);
    editor = pref.edit();
  }

}

and to save the password, I used an algorithm to encrypt and decrypt

encrypt algorithm

 public void setPassword(String password) {
      int len = password.length();
      len /= 2;
      StringBuilder b1 = new StringBuilder(password.substring(0, len));
      StringBuilder b2 = new StringBuilder(password.substring(len));
      b1.reverse();
      b2.reverse();
      password = b1.toString() + b2.toString();

    editor.putString("password", password);
    editor.apply();
  }

decrypt algorithm

  public String getPassword() {
    String password = pref.getString("password", null);
    int len = password.length();
    len /= 2;
    StringBuilder b1 = new StringBuilder(password.substring(0, len));
    StringBuilder b2 = new StringBuilder(password.substring(len));
    password = b1.reverse().toString() + b2.reverse().toString();
    return password;
  }

NOTE:

In this simple algorithm, I split the password from the middle into two pieces, turned it upside down, and put it back together. It was just an idea and you can use your own algorithms to change how to save the password.

FULL CODE

import android.content.Context;
import android.content.SharedPreferences;

public class PrefManager {

  private SharedPreferences pref;
  private SharedPreferences.Editor editor;

  public PrefManager(Context context) {
    pref = context.getSharedPreferences("PROJECT_NAME", Context.MODE_PRIVATE);
    editor = pref.edit();
  }
  public String getPassword() {
    String password = pref.getString("password", null);
    int len = password.length();
    len /= 2;
    StringBuilder b1 = new StringBuilder(password.substring(0, len));
    StringBuilder b2 = new StringBuilder(password.substring(len));
    password = b1.reverse().toString() + b2.reverse().toString();
    return password;
  }

  public void setPassword(String password) {
      int len = password.length();
      len /= 2;
      StringBuilder b1 = new StringBuilder(password.substring(0, len));
      StringBuilder b2 = new StringBuilder(password.substring(len));
      b1.reverse();
      b2.reverse();
      password = b1.toString() + b2.toString();

    editor.putString("password", password);
    editor.apply();
  }
}

View more solutions

Comments

[VahidHoseini]

this works correctly : stackoverflow.com/a/19629701/5733853

[androniennn]

Any tutorial please of how hashing a password? I'm interested in that idea. And no one can retrieve the stored password with that technic?

[Marvin Pinto]

@androniennn There are a ton of tutorials on how to hash passwords so I'll let you Google that. One thing to keep in mind is that hashing is only meant to thwart the casual snooper. This technique has no effect when the device is rooted (for example), and the malicious user has access to your binary as well. Think about it, if someone can reverse engineer your program, then they can easily figure out how you hashed the password. You just need to be aware of the possibilities is all :)

[Gnanam R]

storing in SharedPreferences is clearing data if my device re-booted. Is that happening only to me ??

[Tyler]

Why dont you 1-way hash, using something like Sha-1.. then all you have to do is check to see that the hashes match, not if the decrypted plaintext matches.

[Dirty Henry]

I agree on everything you said technically speaking. But I feel the more public your blood type is, the more likely you can be saved in case of emergency ;)

[batbrat]

The tutorial link is broken, so I'm not sure if it is the same, but a Google immediately gave showed me an article that seemed pretty similar: androidsnippets.com/encryptdecrypt-strings, but it occurs to me that you could use a randomly generated seed that is stored off the device for added security. This shared secret/seed would be randomly generated per user and the off-device storage would contain the mapping. So long as you securely exchange information with that location securely, and that storage is secure, wouldn't that work out better?

[knaak]

@batbrat If you are going to have a server side persistent user state, recommend oauth2 rather than something homegrown. In my example, there is no user state and so I had nothing available to call against.

[batbrat]

Thank you for clarifying. I understand better now, and agree.

[Velizar Hristov]

I very much doubt that OAuth can make it secure, at best it can make it harder to crack, at worst it can leave you exposed by its own vulnerabilities. When an attacker has the same data as your application and your application's source code, it is impossible to make it secure.

[FrankS101]

Welcome to StackOverflow! Can you also provide an explanation to help the PO to understand your answer?

[Jesper]

The different links doesn't work. Use this instead. github.com/Medisana/Android-Standalone/blob/master/app/src/m‌​ain/…

[Fernando Gallego]

It doesn't matter if the data is not super-secret, users can use the same user/password in many places and an attacker can get those and try on different services.

[Miha_x64]

Base64 is not encryption, it is encoding algorithm, which is very easy to recognize and decode.

[bakriawad]

@styler1972 that would be the same as using a token from the server, 1-way has can be reversed (even though it is not easy it is still possible), 1 way hashing the token is the best option for best security here. even if someone was to put the time and effort in generating a data that matches the hashed token by then it would have already been expired, where if he was to find your password then, if it is a bank account, say good bye to your money. tokens are good, hashed tokens are best. never keep passwords even if hashed. But as mentioned if the data is not sensitive then it is your call.

[RobCo]

I should note that this technique transfers the responsibility of security to the server really the server already has this responsibility because it needs to handle the logins anyway wether you use this technique or not.

[Girish]

is there any possibility of values getting leaked, one who gets hold of device or rooted device?

[Climax]

Highly unlikely @Girish. If it is backed with hardware crypto devices it is truly difficult if not improbable.

[Climax]

Furthermore, you could use key attestation to determine an extra level of certainty that the device is still trusted (at least by Google).

[Girish]

Could be please give an example of a key attestation.

[Climax]

@Girish I cannot state it better than the docs: developer.android.com/training/articles/…

[Nicola Revelant]

Your pseudo algorithm is not secure as the algorithm requires it to be secret otherwise it won't work and this does not increase security as NO secret algorithm is safer than an open source one. In any case, that type of operation on a string is predictable.

[Nicola Revelant]

Well it seems you have solved every authentication problem. Except that ANYONE can send your username to the server once discovered (and if it is difficult to find out then we will also save the password in clear text)