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.
Related
I am new to this site so I am sorry if there are any inaccuracies in this question. I am trying to create a login system using a local database. Previously I did some research on how to make a login system but still have no luck. I am using something like intent.putExtras() (sorry, not sure what the correct word for that is) to store user's details such as username, date of birth etc, so the following activity can receive the data from the previous activity. However, I just figured out that SharedPreferences is used by many people to implement a login system and I am planning on using it as I have an impression that it is more reliable (correct me if I am wrong). However, I have been implementing a login system using intent.putExtras() and never seen anyone implementing a login system that way. To make sure my current way of implementation is reliable, my question is, can I use intent.putExtras() instead of using SharedPreferences?
intent.putExtras(//something) only stores data in Bundle temporarily. You need to store the user info (or if user has logged in) somewhere, to be accessed next time you open the application.
intent.putExtras() are intended to be used, for example, when you want to pass data from one Activity to another.
Locally, sqlite and shared preferences are your only options.
My question is, can I use "intent.putExtras(//something)" instead of using SharedPreferences?
With what you want to achieve, no you can't.
After you edited your question:
If you only want to pass data then you can do so with intent.putExtras(), if you want to store data locally, then you will have to use sqlite or shared preferences.
I'm still learning Android, including its concepts. Currently I'm creating a login system. When someone enter correct username and password, the application will store user's ID in the SharedPreferences.
What I don't want is, someone tries to edit the "currentUserID" session with any user ID so he can instantly logged in. In PHP, I can store user ID inside $_SESSION and I think it's safe which no one can see inside and no one can edit it.
So how about the security of SharedPreferences? I've already googled and found that anything with root privileges are able to access it.
Sorry if there's anything wrong. Thanks.
You can take look at https://developer.android.com/reference/android/accounts/AccountManager which will help you.
I'm creating an android app which requires a login process. My issue is with implementing a "remember me" function in the app. There are several questions surrounding this issue already on the internet, but I was wondering if there is an easier way than creating public keys for the app or using OAuth (disclaimer: novice developer).
I read the existing questions like How do I implement a 'Remember me' function in an Android Activity? and Security: How should I store ("Remember") a user's username and password for future use? but they suggest two methods of password storage: plaintext in SharedPreferences, or hashed in SharedPreferences. However, the answers go on to say that these can be compromised if someone has access to the phone.
As a preliminary question, I would ask whether it is necessary to maintain security once someone has root access to the device/the hashed password, considering that cracking the password may give the intruder access to other accounts the user has made. If so, would it be beneficial to implement a system which performs this function but without ever storing the user's password (plaintext or hashed) on the phone.
I was thinking of a method which works using three steps:
When a user successfully logs in AND has checked the "remember me" checkbox, store their username in a SharedPreferences file.
Store a boolean value in the database indicating whether the user has checked the "remember me" box.
When the app starts in future, it automatically checks the SharedPreferences file for a username. If a username is found, and the database value for that username is true, the user is logged into the app under that user name.
This way, the user's password is never stored on the app (either in cleartext or in hashed form). Would this be a secure way of implementing the "remember me" function, or should I use another method?
Apologies if this question is not specific enough/too open-ended.
As you do not store password in phone I think it's a secured way of implementing a "Remember Me" function. But, In your 3rd step you haven't mentioned how you will get the username to compare with the SharedPreferences. If users have to provide the username again it won't be a good method.
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.
I want to lock my application with a password which the user has set in the applications settings.
Each time the main acitivity of my app is going to be shown, a password dialog should be shown instead. I know how to do that, but i wonder... :
How do I store the password the user has set? I can't store it in SharedPreferences because you can delete SharedPreferences in your phone's settings. I thought about a textfile which holds the password, but this file can be deleted, cant it?
Any ideas?
You cannot protect against the password being deleted one way or another, so you need to step back and consider why you have a password in the first place. Most likely you're using the password to protect data the app has access to, rather than the actual app itself (since protecting the app from running is not going to be effective against an attacker that has physical access to the device.
If your password is to protect data, you only need to ensure that an attacker cannot access the data due to deleting a password store. One way to do this is to use the password as an encryption key (or part of a key) that obscures the data -- thus there's not even a password to delete.
One option is to put the password in the same file as where you have the other information (I reckon you want to protect the settings/data of the user). Just do not start the app when that file is missing or corrupted. What you have accomplished then, is that the information is rendered unusable if someone tampers with the data. Sign / encrypt your data file(s).
Another solution could be to store the password (hash!) on a webserver.