I have a simple RESTful backend and I am using HTTP Basic over HTTPS for authentication. It works fine, but I am looking for a appropriate solution to store the credentials (username + password).
There are a lot of examples out there and the majority suggest to use the Account Manager to store passwords. AFAIK the account manager stores only OAUTH (and similar) accounts and automatically generates tokens etc. But how can I use it to store and fetch the original passwords? Is it even possible?
Others suggest to store it as a hashed value, but this doesn't make sense to me (At the end of the day I will need to have access to the original string).
Sorry for another How to use HTTP basic and android question, but I was not able to find a suitable answer so far and to store the data within the local sqlite db as plaintext doesn't seem to be appropriate.
I have a few thoughts concerning your project/style of usrmanagement.
Why do you want to save the password on the device?
Why don't you work with auth tokens
Why not workig with the good old sharedPreferences.
I would suggest to do it like this.
At first register(no password and username are neccessary, it creates a user "Guest123") or login to the server with a password (hashed by the device, getting from a normal edittext from the user).
Then check for correctness on the server, if valid, send back an auth token and a time to live for that token.
Store this in the sharedpreferences.
Send the token with every request you make to the server, if this token is not valid (because time is over, logged in on another device...), tell the user.
There are couple of tweaks which could be done here, but for the beginning it shoul help ou on your project.
Of course you can use the Account Manager to store password as well. This is the method:
addAccountExplicitly (Account account, String password, Bundle userdata)
and you can get the password using this method:
getPassword(Account account)
Related
I am making an app, and in that app, users login and I am storing their information; however, I have noticed that I don't have a users' password information after they register. Is it a good idea to store users' password when they register through Firebase? And is there a point where I will need their passwords? I want to make sure before I proceed further. Thanks!
You do not do that.
Use the (awesome, amazing) Firebase authentication system.
Click right here:
on the left, to see all the users - click "Authentication".
You never see / you cannot see their passwords.
You don't handle or touch the passwords at all.
In the Android or iOS app, you get the userid - and that's it.
The answer by #PeterHaddad shows perfectly how to do that.
That's the first and most basic step in any Firebase ios/droid app.
In your data you'll have a "table" called probably "userData/" and that's where you keep all data about the user. (For example, you may store their address, real name, shoe size .. whatever is relevant in your app.)
Note - FBase is so amazing, your users can also connect with other methods (phone, etc). For your reference in the future, that is explained here
You don't need to store the password in the firebase database, after you authenticate the user using createUserWithEmailAndPassword the email and other info will be stored in the authentication console. So you do not need the password in the database, all you need is the userid to connect auth with database.
FirebaseUser user=FirebaseAuth.getInstance().getCurrentUser();
String useruid=user.getUid();
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've got an Android app. When a user logs in, the username will be preserved in sharedpreferences. However, I'm not quite sure what to do with a webView in it. Specifically, I created a html file to display some personal info, but I'm not sure how to preserve the log-in state for the webview so that the website knows which specific user is querying.
Please help me out!
Use token based authentication.
You authenticate via your API with your credentials
If successful, you get a token (guid or some other random string) that you pass in from there on out. It's safe to store because it expires after inactivity.
If your token becomes stale, you ask them to re-auth
Keep in mind the web service is going to have to hold a relation from the token to the user in the back end, and will have to be supported by you.
There are more elaborate schemes, as this is a primitive methodology, albeit an answer to your question.
There is a website with a lot of users. In order to use the private pages the user has to login with username and password.
Now I'm working on a android app that displays content from the website via an API in a native way, no WebView or similar. The workflow would be the following:
App is started
App checks if a sessionkey exists.
If the key exists, ask the website API if the sessionkey is valid and belongs to the user
=> if so, allow the usage of the app
If no sessionkey exists, ask for username+passwort, ask the API if it's correct and get a new sessionkey via the API => allow app usage
User clicks on e.g. "account balance"
-> API request is done with the stored sessionkey and the result is displayed
User clicks on "payout", fills in a form and gets his money
-> API request is done with the stored sessionkey and the result is displayed
Now I'm searching for a best practice solve for this. I don't want my sessionkeys to be simply hijack-able and I want to be sure that the sessionkey realy belongs to this user. As private data can be seen/modified via the app, privacy is important.
I took a look at oAuth but this isn't what I need I think because I need a consumer key and consumer secret that is unique for every user and I can't integrate this into the app. I don't want to have a new window/browser for entering username+password and handle the response via a callback like oAuth is doing.
Any hints on this?
Thanks a lot!
For a good starting point on http authentication best practices, have a look at this article:
"Principles for Standardized REST Authentication".
If you want to send private data, you need to use HTTPS. That will also take care of securing your session tokens, etc. If you need to check what token belongs to what user, you naturally need to have this mapping on the server side. Most server side platforms give you a session map or similar, keyed by session ID, etc. and you can store pretty much anything in it, including user details.
I working for an app that requires google login. I need to access provider_uid, email, display name, first name, last name.
I managed to iterate all google accounts from the device and present them in a list. After the user perform a click on a list item, I access the selected account auth_token via AccountManagerCallback. But I need provier_uid(an example: https://www.google.com/accounts/o8/id?id=Alt....) and the fields enumerated above. I suppose I must perform some request to google server where to query this information (and passing account token key to request), but I didn't find any docs for this(only authentication, authorization - using ClientLogin, OAuth 2.0 and OpenId).
It's my first time when handling google auth(except picassa and yoututbe auth+upload).
I need this to update a database and be able to authenticate the user(which has the option to upload images and do other things on my server).
Thanks,
Alex.
I found a solution to this problem ( Webservice credentials - OpenID/Android AccountManager? - see Igor Zubchenok answer).
Now I send the auth token to my server where I use gdata/gauva jars to getter informations about the account.