Currently, as per sample app of quickblox, Account key, Service Key and Service secret is stored in app itself.
My concern is that anybody can easily reverse engineer an app to get these secrets and create any number of fake account to troll other users (or even delete accounts?).
Alternatively, even if I generate session token on server, a user can get hold of this token and (as per my understanding) achieve the same thing as above.
What I want is to give user just enough information to login with his server generated credentials and send/receive messages.
Is there a way to achieve this? Maybe something like creating a session on server which allows only login and chat.
The right way is to obfuscate your Account key, Service Key and Service secret values
there are a lot of ways to do it, also ProGuard can help with this
You also can create a session token on a server side and pass this token to your app by some way, for example to have another backend with such API, so end user will request a token from that API and next just use it withiut storing any sensetive data inside an app
Related
I've been mostly creating smaller apps and games for Android so far, but am now creating a somewhat big app with lots of users and more sensible data than a highscore.
My normal approach was to just have a table for all users with passwords, authenticate with a simple Login Screen using a HTTP(S) call and that's it.
There's a few things I want to improve for this app though:
Secure Transmission
If I want to encrypt the user's password, where do I need to do it? On the device, before it's even sent? (In case of unsecure networks, like a public WiFi hotspot) Or better on the server, before writing it into the DB? Or should I just use SQL's encryption?
Auto Login
I want users to be able to stay logged in until the log out - how would I best do that? Not just security-wise, but also for the user experience.
My research shows me that using the AccountManager would be best to save the username and password and authenticate automatically when the app is started. Is there anything more to it, any security risks I'm missing here?
Access control
Usually, I would just expect every call made by an app to be valid, since a user can't access anything but the login screen without logging in. But how do I best authenticate a user's request to make sure that it's not an attacker? I can't just send the username/id with every request, so I probably need like a session token that I generate on each login? Or is there a better method?
Is there anything else I've forgot to think about?
I would suggest you to transfer password without encrypting it but by https. Other way would be to implement asymmetric encryption in your app and encrypt password with public key which you will receive from server.
On the server side I would hash password using some hashing algorithm with salt. And store only hash and salt. When users will log in, you can hash incoming passwords the same way and check hashes on equality.
To make auto login, you need to sign all requests from authorized users with a token. Token you will receive from the server after successful login. This token could be stored in Keystore, or special storage which is accessible only for this application.
Signing could be implemented by attaching to request additional parameter with checksum from all request parameters and token.
Additionally I would suggest you to think about unauthorized clone apps, which could pretend to be your app and call your server side API.
I'm trying to build an app using Google Cloud Messaging.
I used the google gcm samples, with almost no modifications, and so far, I can send message between my client app and my personnal little php server. (no code problem here)
In samples, google let a sendRegistrationToServer() method (click here) for me to write when InstanceId is set, but I don't find any clue on the net about how to manage such things.
How should my database look like to handle users and tokens ?
(if someone could provide a little database structure example, it would make my day !)
Since tokens register an app or a phone and users a user (which imply a registration activity to get username and password, and I haven't made it yet), I kind of don't want to mix them in the same table,
but I might have misconceptions about the purpose of token.
For instance, I wonder why nobody seem to save the token in SharedPreferences...
EDIT : now I get the whole process :
Registration Activity --> Register your user
Send email adress and secured password to your server
Connection Activity --> Connect your user
Get a gcm_token and send it to your server and then map it with connection informations
This seems so simple and clear right now, but really didn't back then, so maybe it could help someone else...
The token may change so it is not useful to store it in shared preferences its better to call InstanceID.getToken so you are sure you always get the correct token value. The important thing is to know whether or not you have sent the latest token to your application server, this boolean should be stored in shared preferences.
You should have a class that extends InstanceIDListenerService in which you implement onTokenRefresh to handle new tokens.
You should map your app-generated user IDs to tokens, note that a single user may have many valid tokens associated with them. You don't have to store the tokens with your user's username's and passwords but there should be some mapping of user IDs to tokens.
Eg:
User (uid, uname, pword)
Token (uid, token_value)
A gcm should be associated with a user object.
Once a user gets his gcm token, its a user token and not device token as you might think.
For a simple database integration within your app i suggest you to use Parse.com and their android guide for getting started.
The token is getting authorized each time you open the app, and it might change along time - thats why nobody saves it and reusing the same token evreytime
We have a working website and now developing android application. Some API calls are public however some api calls requires valid user. One server side it is being maintained through sessions and cookies. How can I communicate with server securely from app. I want that user login once until user press logout or uninstall the app. I don't want to store user username and password in app because it can be easily access by anyone if device is rooted and also I don't have password if user is using facebook login method. What should I do to in app and on server side to make it secure and easy. I think apps like facebook etc use those type of approaches in their apps which I am searching.
I have done research on this and found only that I should use static HttpClient.
I am using volley library for network calls because it suites me.
You use a token. When the user logs in (over an HTTPS webservice), he sends up his username and password. The server stores that in a database and returns a token, just like a cookie would. All future requests from the app to the webservice should be done over HTTPS and should have that token as one of the parameters. The server can then lookup who it assigned that token to in its database, and send the user the appropriate data. If the token isn't there or isn't in the db, you return an error. When the user logs out, you delete the token from the DB.
The token number space needs to be big enough that a random token can't be guessed. Using a second piece of data on each request (such as user name, or something identifying the phone such as ANDROID_ID) would help prevent guessing attacks. And of course if you get repeated requests from someone with bad tokens you should treat that as an attack, just like you would with bad cookies.
I have an Android app that connects to a .Net api for receiving/setting data. The confusion that I have is regarding how to signup/login the user first time and authenticate it every time he makes a request to the api.
If I just use username/password based authentication would that be
safe enough? And should I save that username/password in the device
for every api request to the server authenticate him and then serve
his request?
Should I issue a GUID for every user at the signup, save it in
their device and retrieve every time during an api request?
What other patterns are available and which are most efficient and secure.
First important note - don't store passwords anywhere - in your DB store it hashed and not in plain text.
In general, you want a flow where you create a session for the user and use that on
subsequent requests. So, when your user logs in you validate the user/password hash combination and issue a session for the user. In your application you store the session and use it on future requests, until the user logs out or the session expires (usually you set an expiration to sessions).
There are also some generic auth flows you can look at, like oauth2.
I also strongly suggest going throw some documentation on authentication flows best practices.
You can start with these:
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
http://codingkilledthecat.wordpress.com/2012/09/04/some-best-practices-for-web-app-authentication/
I'm interested in the best way to do user auth in a mobile app. At the moment the set up is quite simple. I'm storing the username and password on the app and sending it to the api each time I need to run a restricted query.
This I feel is probably the wrong way to go about this.
Would a better way to be to send the username and password when the user logs in and then store that user's id? The problem with this is that then the api accepts a user id and not a username and password. A user id will be much easier to "guess" at and malicious persons would be able to submit a req to the api with randomly selected user id's performing actions under their account. I have an api key. Is this secure enough?
The issue is that I want to start integrating twitter and facebook oauth into the app. I haven't read much about it, but I think you get a "token". How would this work with the set up that you're suggesting? Would there be benefit to creating a token in my own database of users and using the token (whether it be mine, facebook's or twitter's) as the authorisation? Or would it make sense to keep each service separate and deal with them separately?
Thank you.
The correct way would be to generate auth token on the server when user logs and send this token in login reply. Then this token is used in subsequent requests.
This means that server must keep track of auth tokens it generates. You can also track token creation times and make tokens expire after some time.
Token must be a sufficiently long random string, so that it can not be easily guessed. How to do this was answered before: How to generate a random alpha-numeric string?
Personally I prefer the UUID approach.
Update:
This problem was already solved in web browsers, via cookies and sessions. You can reuse this mechanism in your Android requests (though some REST purists disprove this approach):
Enable sessions on server.
When user logs into a server add some data to session, for instance time of login:
request.getSession().setAttribute("timeOfLogin", System.currentTimeMillis());
Since sessions are enabled, you also need to enable support for cookies in your HttpClient requests: Using Cookies across Activities when using HttpClient
Every time a request is made, server should check if session contains timeOfLogin attribute. Otherwise it should return HTTP 401 reply.
When user logs out, call server logout url and clear the cookies on client.