We are developing a mobile app which will talk to a backend service hosted on Amazon ec2. One part of the app is registration. The registration data will be passed from the phone to the backend ec2 server as rest/JSON. The problem we have is how to make sure the registration request that we receive in the amazon(from the phone app) is from a valid app and not from spammers/hackers? I can't store any id, public key or something similar on the phone app as a clever person can easily decompile the code and get that logic. I am sure there would be some solution out side which others have implemented.
Some solutions in my mind are: Some sort of Token Synchronisation/One time token etc.
Please suggest some good solutions people out there have implemented.
Related
My company that I'm interning at is currently using Firebase push notification tokens for authentication from the mobile app to the backend and I am not sure if this is a good practice. The way it works is as follows:
FirebaseInstanceID service issues a unique token for every device as
soon as device starts
Mobile user sends login info to server; if server authenticates, the
mobile app then uploads the Firebase token to the database and it is
stored with the user such that the token matches with the user
On any subsequent logins, user sends the Firebase token retrieved from FirebaseInstanceID service to the server; the server attempts to match the token with a user
On clicking logout, mobile phone sends an empty token (i.e. empty string) to the server with their associated username
I have a feeling this is a very bad way to do authentication but I don't quite know why. According to my research the conventional way to do is that the server sends a temporary session ID to client, client stores it securely, and sends it to server for any subsequent requests. Can somebody explain what's going on with this Firebase business and why its good or bad?
The problematic your company is facing, from what i understand, it to authenticate devices with a back-end API.
Actually when it comes to mobile applications, it is a tricky question. If users do not have to authenticate personnally, you still don't want to open your services to anyone. So you want to have an automated authentication system that runs in the background of your mobile app and that identifies devices or app instances.
To do that you need two things : 1 - identify a device (or an app instance) in a unique manner. 2 - make sure that the used string to identify the device/app instance comes from a real device/app instance.
Firebase instance ID is maybe right now the best free way to do that. The mobile app asks for google services to generate the unique token. The mobile app then sends the token to your back-end API for authentication.
And then the back-end API makes sure, during authentication, that the sent token comes from a real app instance by making a request to google services. Google services ensure that the token was generated on a real device (android/ios) and refer to an instance of your app (and not a tampered one).
This is a good way of delegating security issues that I exposed above to google services (who probably are better than you if you're not a security expert).
Of course there are other security measures that you should take to ensure your back-end API integrity. Such as HTTPS, for instance..
So I guess when it comes to mobile development, we should hope for a better solution than that, but since there are no better solutions, using firebase instance id is not bad practice.
Hope this helps
I have a background in web development but I am very new to the mobile world. So, I'm not sure how to proceed with this situation:
The user login in the app
The credentials are sent to the server through a POST request.
If the response is ok, it redirects to the main activity.
Now, I want to know if I have to keep the user's ID or not. I know that when we are using a browser the server saves a "session" so the client doesn't need to send the ID everytime to request data. Is that also true with mobile apps (Android)?
By the way, I'm also responsible for building the REST API but don't have any experience targeting mobile devices.
Big question to answer, and it depends and not sure what server technology you are using. However I can describe an approach I implemented (.Net background).
It seems you are writing a mobile app?
The mobile app would first make an authentication call passing id and password to your login api, over https of course. Often the url would be something like
//yourwebsite/Account/Token
Your api would validate the user and if ok, issue a bearer token.
The mobile app needs to remember this token and on subsequent calls pass this in the request header. That's how the server will know who this is. You don't need to send the user id and password any more. And there may be a strong security argument for not storing the user id and password on the mobile device at all.
Now, your server code will validate the token, and you will know who and what the user can do. The token typically expires, so any mobile client needs to check for this and re-authenticate to get a fresh token.
But how will the server know this token, who it belongs to?
In an MVC world for example, there's framework code to help here. There's plenty of MVC template code. If you happen to be developing .Net api services, see this http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
If you are not .Net on the server, I'm sure there will be something else to help you along the same principals.
As for developing RESTful API's, ServiceStack is seriously worth considering. If too expensive, at least consider their approach and roll your own (especially when it comes to versioning of your api's).
You misunderstand the case with browsers, therefore your conclusion is flawed. Let me explain: When you log in to a website using a web-browser, a session is saved indeed, but not only on the server. It is saved at the client-side as well. Whenever you send a request from there on to the server, you have to send that stored information as well, called cookie to identify yourself.
Let's think about this more deeply: How would a server identify your session as being your session without getting a cookie? By IP address? Nope, the IP address can be used by many and it might change. By browser session? Yes, by browser session, which includes the cookie as well.
Now that you understand that the session is saved by both the server and the client, you surely already know that you need the very same for mobile apps as well. The client logs in, therefore a cookie is generated for the client. This should be difficult to guess. From there on, the client uses the server using the cookie created for it.
If you do not believe me, visit a website where you are not logged in, and then run console.log(document.cookie);, log in, then run console.log(document.cookie) again, then log out andd run console.log(document.cookie) again.
I have an app that retrieves data via http from a server. App sends a POST request with some variables to execute the query and retrieve the data in a JSON format.
The problem is I don't find a way to make the data secure into my server (only accessible to users that have MY application installed). If someone gets my app, and decompile it (even ProGuard won't avoid this for too long) a modded app could start sending requests to my server, using exactly the same protocols, parameters and IP address.
So, in a nutshell, the question is: Is there a way to check (server side, of course) if a request is coming from a legit user?, any way to check if the requester is using my app and not a modded one?
PS: I've been looking for questions like this one and only found another close one that suggested a "user login" approach as answer. I don't want to bother my users with any login mechanics.
Thanks in advance.
Google offers a method to verify back-end calls from an Android app as part of Google Play Services which allows you to verify that the back-end call came from your signed application. One advantage that it has is there is no user login required to verify calls due to the client ID scope used to get the auth token.
This is an "Is this possible?" question. I have an app for the android phone and another application for the appengine platform. The appengine thing is really just a db of high scores, and the phone app is really just a game. I can, using some json/gson/httppost stuff, send the scores from the game to the db. Now I want to make sure that the scores I have collected come from the game, not some guy, maybe talented at programming but with too much time on his hands.
Here's the question. Can I use google OAuth 2.0 to somehow authenticate that the scores I'm getting come from phones running my game?
I thought I'd do this: I'd use OAuth to get some kind of token from google (from the phone), then pass that token to the appengine database (using a json record), then use the token to get info from google on the user. This could be as simple as an email address. Then I'd say to myself "Well, as long as I get an email address for the user, then I know that the user is using the game, and I can store their score." Does this sound possible? I get the feeling that once I use the phone to get the token from google, it's unusable by the appengine program.
I was thinking I'd use the client_id and client_secret, (and whatever else I needed) that were associated with the appengine db to get a token from the phone, then when I sent the token via json to the appenging program to get the email address, they'd work from appengine. This seems like somehow the google OAuth would know that I was trying to get a token from a phone, and then would reject the whole thing. Then again maybe it would work. They say though that android phones cannot keep secrets (referring to the client_secret).
Finally I was wondering if there was any other easier way of making sure that the score I was recording at the appengine side was truly coming from an android phone running my game? Can I set up my own authentication scheme? How hard is this to do?
Good timing; Google just released a feature will address your question:
http://android-developers.blogspot.ca/2013/01/verifying-back-end-calls-from-android.html
Doing this is a multi-step process, which I’ll outline in full, but
here’s the short version: You use the GoogleAuthUtil class, available
through Google Play services, to retrieve a string called an “ID
Token”. You send the token to your back end and your back end can use
it to quickly and cheaply verify which app sent it and who was using
the app.
With OAuth 2.0 (Open ID connect) you can identify the user that is using your game. It seems that you want to authenticate the app though. There are multiple ways to do this, but you still have to embed the credentials in the app or create some sort of registration mechanism. Generally, as long as your attacker (skillful user) has full access to app code and the device (rooted, etc.), there is not much you can do. The only question is who hard do you want to make it.
Or you can use a third party service such as Parse, and trust that they spend some time perfecting their app authentication mechanism.
Suppose you have a mobile application (Windows Phone or Android) that connects yo your back-end using SOAP.
For making it easy, let's say that we have a Web Service implemented in C#. The server exposes the following method:
[WebMethod]
public string SayHallo() { return "Hallo Client"; }
From the server perspective, you can't tell if the caller is your mobile application or a developer trying to debug your web service or a hacker trying to reverse engineer/exploit your back-end.
How can one identify that the origin of the web service call is THE application? as anyone with the WSDL can invoke the WS.
I know I can implement some standard security measures to the web service like:
Implement HTTPS on the server so messages travel encrypted and the danger of eavesdropping is reduced.
Sign the requests on the client-side using a digest/hashing algorithm, validate the signature in the server and reject the messages that have not been signed correctly.
Write custom headers in the HTTP request. Anyways headers can be simulated.
However, any well experienced hacker or a developer who knows the signing algorithm, could still generate a well signed, well, formatted message. Or a really good hacker could disassemble the application and get access to the hidden know-how of my "top secret" communications protocol.
Any ideas how to make the SayHallo() method to answer ONLY to request made from my mobile application?
We are running in the context of a mobile application, with hardware access, there could be something that can be done exploiting the hardware capabilities.
If someone wonders, I'm thinking on how to make a mobile app secure enough for sensitive applications like banking, for example.
Thanks for your ideas.
What you are describing is bi-directional authentication. It can only be done by storing a signed public key (certificate) on boths sides of the communication. Meaning that each app would need to authenticate your server with your servers public key and the server would need to authenticate each instance of your app. The app's public key would need to be produced and stored on the server at the deployment time with each instance of your app. Think of this as 2 way HTTPS, in general the only authentication that needs to be done is one direction, with the browser authenticating the server with a trusted signing key. In your case this would need to be done on both sides. Normally you would have a service like VeriSign sign each instance of a public key, this can get quite spendy with multiple deployments of an app. In your case you could just create an in house signing application using something like OPENSSL to sign your app every time it is distributed. This does not mean that someone still could not hack your code and extract the signing key on the app side. In general any code can be hacked, it's just a question of how hard can you make it before they give up? If you were to go the custom hardware route, there are things such as crypto chips and TMP's that can serve as a key sotre and make it harder for people to gain access to the private keys on the device.
A quick google search turned up the following:
http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication
If you are thinking about using rewards points, and are really worried about someone gaming the system from the outside a better solution is to have each person make an account that is stored securely on the server and their points are saved and tallied there. This centralizes all the data and allows you complete control over it with out worrying about a malicious app reporting non-existent points. (this is how banks work)
If you want to verify that a user is both mobile and who they say they are then the best way is to leverage the network. Send a push notification with the hashed key that you want the user to use via:
APN for iOS
something like urban airship for windows phone
GCM for Android.
In general, the model looks like:
Server authenticates itself to the many clients with a certified public key (this is the whole Public Key Infrastructure, Certificate Authorities, etc)
Each client identifies itself to the server via some other authentication system (in 99.9% of cases, this is a password)
So if you're wondering how this sort of thing works in the case of banking apps, etc that's basically how it breaks down: (1) Client and server establish a secure channel such as a shared secret key, using the server's public key, (2) Client authenticates via this secure channel using some other mechanism.
Your question specifically, however, seems more aimed at the app authenticating itself (i.e., any request from your app is authentic) with the thought that if only your app can be authenticated, and your app is well-behaved, then everything should be safe. This has a few implications:
This implies that every user of your app is trusted. In security terms, they are part of your "trusted computing base".
Attempting to achieve this sort of goal WITHOUT considering the user/user's computing platform as trusted is essentially the goal of DRM; and while it's good enough to save money for music publishers, it's nowhere close to good enough for something really sensitive.
In general:
The problem that you're specifically looking at is VERY hard to solve, if you're looking for very strong security properties.
You likely don't need to solve that problem.
If you give us some more context, we might be able to give you more specific advice.
In addition to the answers already given, how about using a login type scheme with the unique id of the phone and a password? Get the user to register with your "back-end" and every time a transaction has to be made with the back-end, require the password or have an option to automatically log in.
You can use the following way to secure and to track your requests to server.
You can force the mobile or web clients to send you a Custom Headers of the device type when accessing your webservice through REST methods
Use basic http authentication by forcing each client to have their own username and passwords provided by you as a authorized webservice provider..
If you need more advanced protection you can use OAuth 2.0 to secure your webservice.
Since your originating app is going to be Android or Windows Phone apps, either one of them will be relatively easy for the wanna be hacker to debug. in any case you're going to be running the code on a machine that you have no control over so no ssl tricks or checking signing will solve your fundamental problem.
the only way you can combat threat from it is to NOT TRUST THE CLIENT. verify that the input coming from the clients is valid before acting on it if you're making a game - that it's accompanied by a valid security token etc.
in essence build your service so that it doesn't matter if the user is using an unofficial client.