sharedpreferences encryption - Android SharedPreference security

hack username (4)

SharedPreferences are nothing but XML files in your phones /data/data/ folder,So any application or user with superuser privilages on a rooted device can access your SharedPreferences, even if they were created with MODE_PRIV

Still there is a way to protect it from everybody... Please checkout this link. Here you can store data in pref with encryption,the class is self explanatory and very easy to use.

As said by others anyone can access it but in this case no one can read data inside it as it is encrypted. So its secure.For Utmost security my suggestion will be to generate the key used for encryption at run time rather than hard coding it. There are many ways to do that :)

I wonder about shared preferences security.

Is it possible to get access to sharedpreferences, even if they were created in MODE_PRIV (0) ?
Is it possible to list all sharedpreferences available and then fetch all settings from other apps?
Is sharedpreferences good place to put sensitive data, such as password or auth token?


Shared Preferences are stored as a file in the filesystem on the device. They are, by default, stored within the app's data directory with filesystem premissions set that only allow the UID that the specific application runs with to access them. So, they are private in so much as Linux file permissions restrict access to them, the same as on any Linux/Unix system.

Anyone with root level access to the device will be able to see them, as root has access to everything on the filesystem. Also, any application that runs with the same UID as the creating app would be able to access them (this is not usually done and you need to take specific action to make two apps runs with the same UID, so this is probably not a big concern). Finally, if someone was able to mount your device's filesystem without using the installed Android OS, they could also bypass the permissions that restrict access.

If you're concerned about such access to your preferences (or any data written by your application), then you will want to encrypt it. If you are that concerned about them, you're going to need to figure out exactly how much protection is necessary for the level of risk you see. There is a very extensive discussion about this in Application Security for the Android Platform, just published in December 2011 (disclaimer: I'm the author of this book).

Normally, no, they cannot be accessed by other apps, however, you should note that SharedPreferences are stored as XML files in the /data/data/ directory, which essentially means that any application with superuser privileges on a rooted device can access your SharedPreferences, even if they were created with MODE_PRIV


A lot has been said about Password encryption for PHP, most of which is very good advice, but before you even start the process of using PHP for password encryption make sure you have the following implemented or ready to be implemented.



No matter how good your encryption is if you don't properly secure the server that runs the PHP and DB all your efforts are worthless. Most servers function relatively the same way, they have ports assigned to allow you to access them remotely either through ftp or shell. Make sure that you change the default port of which ever remote connection you have active. By not doing this you in effect have made the attacker do one less step in accessing your system.


For all that is good in the world do not use the username admin, root or something similar. Also if you are on a unix based system DO NOT make the root account login accessible, it should always be sudo only.


You tell your users to make good passwords to avoid getting hacked, do the same. What is the point in going through all the effort of locking your front door when you have the backdoor wide open.



Ideally you want your DB and APPLICATION on separate servers. This is not always possible due to cost, but it does allow for some safety as the attacker will have to go through two steps to fully access the system.


Always have your application have its own account to access the DB, and only give it the privileges it will need.

Then have a separate user account for you that is not stored anywhere on the server, not even in the application.

Like always DO NOT make this root or something similar.


Follow the same guidelines as with all good passwords. Also don't reuse the same password on any SERVER or DB accounts on the same system.



NEVER EVER store a password in your DB, instead store the hash and unique salt, I will explain why later.


ONE WAY HASHING!!!!!!!, Never hash a password in a way that it can be reversed, Hashes should be one way, meaning you don't reverse them and compare them to the password, you instead hash the entered password the same way and compare the two hashes. This means that even if an attacker gets access to the DB he doesn't know what the actually password is, just its resulting hash. Which means more security for your users in the worst possible scenario.

There are a lot of good hashing functions out there (password_hash, hash, etc...) but you need to select a good algorithm for the hash to be effective. (bcrypt and ones similar to it are decent algorithms.)

When hashing speed is the key, the slower the more resistant to Brute Force attacks.

One of the most common mistakes in hashing is that hashes are not unique to the users. This is mainly because salts are not uniquely generated.


Passwords should always be salted before hashed. Salting adds a random string to the password so similar passwords don't appear the same in the DB. However if the salt is not unique to each user (ie: you use a hard coded salt) than you pretty much have made your salt worthless. Because once an attacker figures out one password salt he has the salt for all of them.

When you create a salt make sure it is unique to the password it is salting, then store both the completed hash and salt in your DB. What this will do is make it so that an attacker will have to individually crack each salt and hash before they can gain access. This means a lot more work and time for the attacker.


If the user is creating a password through the frontend that means it has to be sent to the server. This opens up a security issue because that means the unencrypted password is being sent to the server and if a attacker is able to listen and access that all your security in PHP is worthless. ALWAYS transmit the data SECURELY, this is done through SSL, but be weary even SSL is not flawless (OpenSSL's Heartbleed flaw is an example of this).

Also make the user create a secure password, it is simple and should always be done, the user will be grateful for it in the end.

Finally, no matter the security measures you take nothing is 100% secure, the more advanced the technology to protect becomes the more advanced the attacks become. But following these steps will make your site more secure and far less desirable for attackers to go after.

Here is a PHP class that creates a hash and salt for a password easily

android security sharedpreferences