What is the most appropriate way to store user settings in Android application

Question

I am creating an application which connects to the server using username password and I would like to enable the option  Save password  so the user wouldn t have to type the password each time the application starts   I was trying to do it with Shared Preferences but am not sure if this is the best solution   I would appreciate any suggestion on how to store user values settings in Android application

User · Answer

I ll throw my hat into the ring just to talk about securing passwords in general on Android   On Android  the device binary should be considered compromised - this is the same for any end application which is in direct user control   Conceptually  a hacker could use the necessary access to the binary to decompile it and root out your encrypted passwords and etc   As such there s two suggestions I d like to throw out there if security is a major concern for you   1  Don t store the actual password   Store a granted access token and use the access token and the signature of the phone to authenticate the session server-side   The benefit to this is that you can make the token have a limited duration  you re not compromising the original password and you have a good signature that you can use to correlate to traffic later  to for instance check for intrusion attempts and invalidate the token rendering it useless    2  Utilize 2 factor authentication   This may be more annoying and intrusive but for some compliance situations unavoidable

User · Answer

You can also check out this little lib  containing the functionality you mention   https   github com kovmarci86 android-secure-preferences  It is similar to some of the other aproaches here  Hope helps

User · Answer

This is a supplemental answer for those arriving here based on the question title  like I did  and don t need to deal with the security issues related to saving passwords  How to use Shared Preferences User settings are generally saved locally in Android using SharedPreferences with a key-value pair  You use the String key to save or look up the associated value  Write to Shared Preferences String key    quot myInt quot   int valueToSave   10   SharedPreferences sharedPref   PreferenceManager getDefaultSharedPreferences context   SharedPreferences Editor editor   sharedPref edit    editor putInt key  valueToSave  commit     Use apply   instead of commit   to save in the background rather than immediately  Read from Shared Preferences String key    quot myInt quot   int defaultValue   0   SharedPreferences sharedPref   PreferenceManager getDefaultSharedPreferences context   int savedValue   sharedPref getInt key  defaultValue    The default value is used if the key isn t found  Notes  Rather than using a local key String in multiple places like I did above  it would be better to use a constant in a single location  You could use something like this at the top of your settings activity    final static String PREF MY INT KEY    quot myInt quot     I used an int in my example  but you can also use putString    putBoolean    getString    getBoolean    etc   See the documentation for more details   There are multiple ways to get SharedPreferences  See this answer for what to look out for

User · Answer

I use the Android KeyStore to encrypt the password using RSA in ECB mode and then save it in the SharedPreferences   When I want the password back I read the encrypted one from the SharedPreferences and decrypt it using the KeyStore   With this method you generate a public private Key-pair where the private one is safely stored and managed by Android   Here is a link on how to do this  Android KeyStore Tutorial

User · Answer

Using the snippet provided by Richard  you can encrypt the password before saving it   The preferences API however doesn t provide an easy way to intercept the value and encrypt it - you can block it being saved via an OnPreferenceChange listener  and you theoretically could modify it through a preferenceChangeListener  but that results in an endless loop   I had earlier suggested adding a  hidden  preference in order to accomplish this   It s definitely not the best way   I m going to present two other options that I consider to be more viable    First  the simplest  is in a preferenceChangeListener  you can grab the entered value  encrypt it  and then save it to an alternative preferences file     public boolean onPreferenceChange Preference preference  Object newValue             get our  secure  shared preferences file        SharedPreferences secure   context getSharedPreferences            SECURE            Context MODE PRIVATE                String encryptedText   null           encrypt and set the preference        try            encryptedText   SimpleCrypto encrypt Preferences SEED  String newValue             Editor editor   secure getEditor             editor putString  encryptedPassword  encryptedText            editor commit                  catch  Exception e             e printStackTrace                     always return false        return false          The second way  and the way I now prefer  is to create your own custom preference  extending EditTextPreference   Override ing the setText   and getText   methods  so that setText   encrypts the password  and getText   returns null

User · Answer

I know this is a little bit of necromancy  but you should use the Android AccountManager   It s purpose-built for this scenario   It s a little bit cumbersome but one of the things it does is invalidate the local credentials if the SIM card changes  so if somebody swipes your phone and throws a new SIM in it  your credentials won t be compromised   This also gives the user a quick and easy way to access  and potentially delete  the stored credentials for any account they have on the device  all from one place   SampleSyncAdapter is an example that makes use of stored account credentials

User · Answer

About the simplest way to store a single preference in an Android Activity is to do something like this   Editor e   this getPreferences Context MODE PRIVATE  edit    e putString  password   mPassword   e commit      If you re worried about the security of these then you could always encrypt the password before storing it

User · Answer

This answer is based on a suggested approach by Mark  A custom version of the EditTextPreference class is created which converts back and forth between the plain text seen in the view and an encrypted version of the password stored in the preferences storage    As has been pointed out by most who have answered on this thread  this is not a very secure technique  although the degree of security depends partly on the encryption decryption code used  But it s fairly simple and convenient  and will thwart most casual snooping    Here is the code for the custom EditTextPreference class   package com Merlinia OutBack Client   import android content Context  import android preference EditTextPreference  import android util AttributeSet  import android util Base64   import com Merlinia MEncryption Main MEncryptionUserPassword           This class extends the EditTextPreference view  providing encryption and decryption services for    OutBack user passwords  The passwords in the preferences store are first encrypted using the    MEncryption classes and then converted to string using Base64 since the preferences store can not    store byte arrays        This is largely copied from this article  except for the encryption decryption parts     https   groups google com forum   topic android-developers pMYNEVXMa6M     public class EditPasswordPreference  extends EditTextPreference           Constructor - needed despite what compiler says  otherwise app crashes     public EditPasswordPreference Context context            super context                  Constructor - needed despite what compiler says  otherwise app crashes     public EditPasswordPreference Context context  AttributeSet attributeSet            super context  attributeSet                  Constructor - needed despite what compiler says  otherwise app crashes     public EditPasswordPreference Context context  AttributeSet attributeSet  int defaultStyle            super context  attributeSet  defaultStyle                          Override the method that gets a preference from the preferences storage  for display by the        EditText view  This gets the base64 password  converts it to a byte array  and then decrypts        it so it can be displayed in plain text          return  OutBack user password in plain text              Override     public String getText             String decryptedPassword           try               decryptedPassword   MEncryptionUserPassword aesDecrypt                       Base64 decode getSharedPreferences   getString getKey         Base64 DEFAULT              catch  Exception e                e printStackTrace                decryptedPassword                          return decryptedPassword                         Override the method that gets a text string from the EditText view and stores the value in        the preferences storage  This encrypts the password into a byte array and then encodes that        in base64 format          param passwordText  OutBack user password in plain text              Override     public void setText String passwordText            byte   encryptedPassword           try               encryptedPassword   MEncryptionUserPassword aesEncrypt passwordText             catch  Exception e                e printStackTrace                encryptedPassword   new byte 0                      getSharedPreferences   edit   putString getKey                                              Base64 encodeToString encryptedPassword  Base64 DEFAULT                    commit                 Override     protected void onSetInitialValue boolean restoreValue  Object defaultValue            if  restoreValue              getEditText   setText getText             else             super onSetInitialValue restoreValue  defaultValue             This shows how it can be used - this is the  items  file that drives the preferences display  Note it contains three ordinary EditTextPreference views and one of the custom EditPasswordPreference views    lt PreferenceScreen xmlns android  http   schemas android com apk res android  gt        lt EditTextPreference         android key   string useraccountname key          android title   string useraccountname title          android summary   string useraccountname summary          android defaultValue   string useraccountname default            gt        lt com Merlinia OutBack Client EditPasswordPreference         android key   string useraccountpassword key          android title   string useraccountpassword title          android summary   string useraccountpassword summary          android defaultValue   string useraccountpassword default            gt        lt EditTextPreference         android key   string outbackserverip key          android title   string outbackserverip title          android summary   string outbackserverip summary          android defaultValue   string outbackserverip default            gt        lt EditTextPreference         android key   string outbackserverport key          android title   string outbackserverport title          android summary   string outbackserverport summary          android defaultValue   string outbackserverport default            gt    lt  PreferenceScreen gt    As for the actual encryption decryption  that is left as an exercise for the reader  I m currently using some code based on this article http   zenu wordpress com 2011 09 21 aes-128bit-cross-platform-java-and-c-encryption-compatibility   although with different values for the key and the initialization vector

User · Answer

you need to use the sqlite  security apit to store the passwords  here is best example  which stores passwords  -- passwordsafe  here is link for the source and explanation --  http   code google com p android-passwordsafe

User · Answer

In general SharedPreferences are your best bet for storing preferences  so in general I d recommend that approach for saving application and user settings   The only area of concern here is what you re saving  Passwords are always a tricky thing to store  and I d be particularly wary of storing them as clear text  The Android architecture is such that your application s SharedPreferences are sandboxed to prevent other applications from being able to access the values so there s some security there  but physical access to a phone could potentially allow access to the values   If possible I d consider modifying the server to use a negotiated token for providing access  something like OAuth  Alternatively you may need to construct some sort of cryptographic store  though that s non-trivial  At the very least  make sure you re encrypting the password before writing it to disk

User · Answer

Okay  it s been a while since the answer is kind-of mixed  but here s a few common answers  I researched this like crazy and it was hard to build a good answer   The MODE PRIVATE method is considered generally safe  if you assume that the user didn t root the device  Your data is stored in plain text in a part of the file system that can only be accessed by the original program  This makings grabbing the password with another app on a rooted device easy  Then again  do you want to support rooted devices  AES is still the best encryption you can do  Remember to look this up if you are starting a new implementation if it s been a while since I posted this  The largest issue with this is  What to do with the encryption key     So  now we are at the  What to do with the key   portion  This is the hard part  Getting the key turns out to be not that bad  You can use a key derivation function to take some password and make it a pretty secure key  You do get into issues like  how many passes do you do with PKFDF2    but that s another topic   Ideally  you store the AES key off the device  You have to figure out a good way to retrieve the key from the server safely  reliably  and securely though You have a login sequence of some sort  even the original login sequence you do for remote access   You can do two runs of your key generator on the same password  How this works is that you derive the key twice with a new salt and a new secure initialization vector  You store one of those generated passwords on the device  and you use the second password as the AES key    When you log in  you re-derive the key on the local login and compare it to the stored key  Once that is done  you use derive key  2 for AES    Using the  generally safe  approach  you encrypt the data using AES and store the key in MODE PRIVATE  This is recommended by a recent-ish Android blog post  Not incredibly secure  but way better for some people over plain text   You can do a lot of variations of these  For example  instead of a full login sequence  you can do a quick PIN  derived   The quick PIN might not be as secure as a full login sequence  but it s many times more secure than plain text

User · Answer

As others already pointed out you can use SharedPreferences generally but if you would like to store data encrypted it s a bit inconvenient  Fortunately  there is an easier and quicker way to encrypt data now since there is an implementation of SharedPreferences that encrypts keys and values  You can use EncryptedSharedPreferences in Android JetPack Security  Just add AndroidX Security into your build gradle  implementation  androidx security security-crypto 1 0 0-rc01   And you can use it like this  String masterKeyAlias   MasterKeys getOrCreate MasterKeys AES256 GCM SPEC    SharedPreferences sharedPreferences   EncryptedSharedPreferences create       quot secret shared prefs quot       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     See more details  https   android-developers googleblog com 2020 02 data-encryption-on-android-with-jetpack html Official docs  https   developer android com reference androidx security crypto EncryptedSharedPreferences

User · Answer

First of all I think User s data shouldn t be stored on phone  and if it is must to store data somewhere on the phone it should be encrypted with in the apps private data  Security of users credentials should be the priority of the application   The sensitive data should be stored securely or not at all  In the event of a lost device or malware infection  data stored insecurely can be compromised

User · Answer

I agree with Reto and fiXedd   Objectively speaking it doesn t make a lot of sense investing significant time and effort into encrypting passwords in SharedPreferences since any attacker that has access to your preferences file is fairly likely to also have access to your application s binary  and therefore the keys to unencrypt the password   However  that being said  there does seem to be a publicity initiative going on identifying mobile applications that store their passwords in cleartext in SharedPreferences and shining unfavorable light on those applications   See http   blogs wsj com digits 2011 06 08 some-top-apps-put-data-at-risk  and http   viaforensics com appwatchdog for some examples     While we need more attention paid to security in general  I would argue that this sort of attention on this one particular issue doesn t actually significantly increase our overall security   However  perceptions being as they are  here s a solution to encrypt the data you place in SharedPreferences   Simply wrap your own SharedPreferences object in this one  and any data you read write will be automatically encrypted and decrypted   eg   final SharedPreferences prefs   new ObscuredSharedPreferences       this  this getSharedPreferences MY PREFS FILE NAME  Context MODE PRIVATE         eg      prefs edit   putString  foo   bar   commit    prefs getString  foo   null     Here s the code for the class          Warning  this gives a false sense of security   If an attacker has enough access to    acquire your password store  then he almost certainly has enough access to acquire your    source binary and figure out your encryption key   However  it will prevent casual    investigators from acquiring passwords  and thereby may prevent undesired negative    publicity      public class ObscuredSharedPreferences implements SharedPreferences       protected static final String UTF8    utf-8       private static final char   SEKRIT            INSERT A RANDOM PASSWORD HERE                                                    Don t use anything you wouldn t want to                                                   get out there if someone decompiled                                                   your app        protected SharedPreferences delegate      protected Context context       public ObscuredSharedPreferences Context context  SharedPreferences delegate            this delegate   delegate          this context   context             public class Editor implements SharedPreferences Editor           protected SharedPreferences Editor delegate           public Editor                 this delegate   ObscuredSharedPreferences this delegate edit                                            Override         public Editor putBoolean String key  boolean value                delegate putString key  encrypt Boolean toString value                 return this                      Override         public Editor putFloat String key  float value                delegate putString key  encrypt Float toString value                 return this                      Override         public Editor putInt String key  int value                delegate putString key  encrypt Integer toString value                 return this                      Override         public Editor putLong String key  long value                delegate putString key  encrypt Long toString value                 return this                      Override         public Editor putString String key  String value                delegate putString key  encrypt value                return this                      Override         public void apply                 delegate apply                        Override         public Editor clear                 delegate clear                return this                      Override         public boolean commit                 return delegate commit                        Override         public Editor remove String s                delegate remove s               return this                       public Editor edit             return new Editor                 Override     public Map lt String    gt  getAll             throw new UnsupportedOperationException       left as an exercise to the reader             Override     public boolean getBoolean String key  boolean defValue            final String v   delegate getString key  null           return v  null   Boolean parseBoolean decrypt v     defValue              Override     public float getFloat String key  float defValue            final String v   delegate getString key  null           return v  null   Float parseFloat decrypt v     defValue              Override     public int getInt String key  int defValue            final String v   delegate getString key  null           return v  null   Integer parseInt decrypt v     defValue              Override     public long getLong String key  long defValue            final String v   delegate getString key  null           return v  null   Long parseLong decrypt v     defValue              Override     public String getString String key  String defValue            final String v   delegate getString key  null           return v    null   decrypt v    defValue              Override     public boolean contains String s            return delegate contains s               Override     public void registerOnSharedPreferenceChangeListener OnSharedPreferenceChangeListener onSharedPreferenceChangeListener            delegate registerOnSharedPreferenceChangeListener onSharedPreferenceChangeListener               Override     public void unregisterOnSharedPreferenceChangeListener OnSharedPreferenceChangeListener onSharedPreferenceChangeListener            delegate unregisterOnSharedPreferenceChangeListener onSharedPreferenceChangeListener                 protected String encrypt  String value              try               final byte   bytes   value  null   value getBytes UTF8    new byte 0               SecretKeyFactory keyFactory   SecretKeyFactory getInstance  PBEWithMD5AndDES                SecretKey key   keyFactory generateSecret new PBEKeySpec SEKRIT                Cipher pbeCipher   Cipher getInstance  PBEWithMD5AndDES                pbeCipher init Cipher ENCRYPT MODE  key  new PBEParameterSpec Settings Secure getString context getContentResolver   Settings Secure ANDROID ID  getBytes UTF8   20                return new String Base64 encode pbeCipher doFinal bytes   Base64 NO WRAP  UTF8              catch  Exception e                 throw new RuntimeException e                         protected String decrypt String value           try               final byte   bytes   value  null   Base64 decode value Base64 DEFAULT    new byte 0               SecretKeyFactory keyFactory   SecretKeyFactory getInstance  PBEWithMD5AndDES                SecretKey key   keyFactory generateSecret new PBEKeySpec SEKRIT                Cipher pbeCipher   Cipher getInstance  PBEWithMD5AndDES                pbeCipher init Cipher DECRYPT MODE  key  new PBEParameterSpec Settings Secure getString context getContentResolver   Settings Secure ANDROID ID  getBytes UTF8   20                return new String pbeCipher doFinal bytes  UTF8              catch  Exception e                throw new RuntimeException e

User · Answer

shared preferences is easiest way to store our application data  but it is possible that anyone can clear our shared preferences data through application manager so i don t think it is completely safe for our application

[java] What is the most appropriate way to store user settings in Android application

Examples related to java

Examples related to android

Examples related to encryption

Examples related to preferences

Examples related to credentials