I'm currently working on an android application that fetches information in a webservice. Those informations are related to a user ( who has a numeric user ID ).
So basically, I do Volley requests on URLs like this one :
http://api.mydomain/user/items with a POST parameter which is the userID I want to retrieve items.
When the user first log in to my app, I actually store his user ID in the Shared Preferences. This is useful for two things :
I can access his ID from anywhere in my application and therefore do Volley request with the current user ID.
I also use it on the application Splashscreen ( I check if there is this value in the shared preferences file and if so, he doesnt have to log in again and he's redirected to the application main activity ).
When the user disconnects from the application, I clear the Shared Preferences file, so he will have to log in again next time he open the app.
So here are my problems :
If a rooted user open the shared preferences file, he will be able to change the user ID, and so his identity.
If i keep this operating mode, I can't store user settings preferences ( Enable notifications etc.. ), which is the purpose of the shared preferences file ( I believe ), because i clear it when user disconnects in order to ask him to log-in again next time.
So, as you may think, I have the feeling that it's not the right thing to do..
What is the best pratice to do what i want to do ?
Keep some kind of "session", to avoid the user having to reconnect each time he launch the app.
Store his user ID in a secure manner, to prevent a malicious user to change it.
Is there a way to encrypt those critical data ? Maybe shouldn't I use a numeric ID, but rather some kind of encrypted key, to make it more difficult to change ?
Are SharedPreferences really used to store user's settings ( Should'nt I rather store it in the database ? )
Thank you in advance for helping me and sorry for bad english.
SharePreferences are used to store such information. I store the Auth token in sharedPref in one of my apps. Yes, if user has rooted the phone, the sharedpreference xml becomes directly accessible but that's something that user has to take care off (since rooting is normally not advisable and if rooted don't handover the phone to a programmer!)
Coming to your scenario, you are deleting the shared preference on app close (disconnect). Seems like you are simply using the shared preference in one app life cycle and not the entire lifecycle (from install to uninstall). You can be better off by using a singleton class here. Singleton class will have one instance per life cycle and you can set the userId and get it from anywhere in the applifecycle!! :
Class mySingletonClass{
private String userID;
privat static mySingletonClass instance;
public static getInstance()
{
if(instance==null) instance = new mySingletonClass();
return instance;
}
//getter setter for userID
}
to set UserID:
mySingletonClass.getInstance().setUserID(String);
to ger UserID:
mySngletonClass.getInstance().getUserID();
Now even if the phone is rooted, the userID is safely residing in heap memory !
If you do want to user SharedPreference for whole app life cycle (install to uninstall) and are worried about phone being rooted and userId being stolen, you can obfuscate the id before storing, but then again you need to store Key in shared preference too which defeats the purpose. Another way can be to store the key on server. Cracker can still snoop in the network calls and access the key but its a long shot.
Related
I'm worried about android security. I am storing the user id in sharedpreferences. I see some programs online that allow you to get into the sharedpreferences if your device is rooted... etc...
How do I prevent my sharedpreferences from being changed?
There is no way to avoid a user being able to change shared prefs. You need to implement security on your back end with session tokens so that even if the front end userid is changed the back end doesn't allow you to make requests because the session token doesnt match the user id. I assume you are asking because you are having you app communicate with a server and dont want the user to be able to see other peoples data. if not may i ask why you need to be able to do this?
read more about them here
Session token - how does it work?
Code like this
SharedPreference mySP = PreferenceManager.gerDefaultSharedPreference(this, Context.MODE_PRIVATE);
Only your app can access this...
I have android connected to a MySQL database, the user would login via email and password which is hashed. Each user has a unique ID number. When they successfully login I can transfer their Unique ID to a Shared Preference in private mode to keep track of users. Would something like this work or does it sound to risky? From what I know is that SharedPreferences is the only method that can remember users so they can close and open your app and won't have to login again.
SharedPreferences is the way to go. It is private, belongs to the context of your application and users can't access it.
Although Shared Preferences is private, remember that rooted users can see any apps' Shared Prefs. Just make sure you don't ever save the password, hashed or not, locally because the hash can always be reversed. It's fine to keep user info, like id and username locally because a bad actor can't really do anything with that. Keeping an access token is the right way to go. If you look at any Shared Prefs of an app with facebook integration you'll see that facebook keeps its token in clear text.
I am planning on storing a unique identifier after a user logs in for the first time on an Android and Apple app. This will make sure that the user can only access data from one device if they try to login through another device as I will flag then as having access. I will save this unique identifier in the devices preferences and use it for requests to get this private data.
With that being said I know the preferences can be deleted or removed. This piece of data isnt needed long term and in emergencies we can reset the users account back as if they never got access yet like for a factory reset or deleted app.
My question is, are there any issues with this? These arent developers so somehow getting access to the user preferences to find that unique identifier and using it elsewhere shouldnt be an issue.
for IOS:
You shouldn't concern your self with that cause there is no need to store the identifiers to user prefs (and it is not a good practice).
You just use:
[[[UIDevice currentDevice] identifierForVendor] UUIDString];
It will return the same value as long as it is called from the same device and same vendor. This is explained in:
http://www.doubleencore.com/2013/04/unique-identifiers/
I want to be able to prompt the users to enter the details required for the app only when it starts up for the first time (not other times). These details will be held in a database on the phone.
Would it be better to check the database each time or put these details in a shared preference? Furthermore, is this type of activity even possible on Android?
Depends on the details really. If it is a large amount of information you might consider using a Database. For just basic identification information, SharedPreferences should be fine.
If you do use a Database, you might consider loading them into your Application object. This would depend on how frequently you use this information in your app.
To check for the first start of the app, a SharedPreference is generally used AFAIK.
Use SharedPreferences or Database depending on the data complexity and its need later on..
Store a Flag in SharedPreferences and set this when user enters the data.
Check that shared preferences flag while on your first activity and redirects accordingly(to Details/one time page) if required.
here even if a user manually deletes data using Settings > Manage app > your app > clear data, Your app will know to get the details then from user....
I'm trying to build an app with a login module. I want to save the user login state so that the end-user will not have to retype his/her credentials except if they have explicitly logged out.
I understand that SharedPreferences can be of some use but I would appreciate it if some one can provide me some of their expert insight in this matter.
use the below link.There is 3 way to store you login details . one is using shared preference and 2nd one way is store in a file and the third one is using sqlite. This will give you the ideas for storing login details.
save user data
You can use any of the three methods that Asish AP references. But for a small amount of data (one user's username, password, login state) SharedPreferences is probably the lightest / easiest.
But whichever way you go, you should make sure that you encrypt whatever you store using one of the Java encryption methods at Encrypt Password in Configuration Files?. Having plaintext credentials sitting around (eg on the SD card) is just way too vulnerable.