I'm about to start the design of an application for Android (and possibly later on iPhone, if I ever get around learning it). In this application I will need to send and retrieve various information to a backend (that me myself also will need to design and code). The information will most likely be in json format.
How would I go about making this data as safely transmitted as possible? Is https the only anser to this? Or are there any other smart solutions to this?
TLS (including HTTPS), where you validate the certificates from the client and the server is the safest mechanism, and doesn't require you to reinvent authentication in some flawed way.
Related
We have developed a service with REST APIs and an Android app that leverages it. We currently don't require our users to authenticate.
We would like to implement a simple mechanism to prevent the random person from invoking the APIs from outside of the scope of the app, mainly to avoid abuses that would spoil the data that we compute.
I stumbled upon this url where they suggest to have authentication enforced by having the server and Android client to share a secret and use that to compute an HMAC to pass along with the request. They claim that they use this approach in Amazon (I have no experience with Amazon AWS yet).
I'm considering to proceed as follows:
store a common secret in the Server and in the Android app (any good idea for obfuscating it, besides using ProGuard?)
Have client and server to communicate over plain HTTP (we don't need confidentiality yet and we will save some CPU) and use the HMAC method to authenticate the calls as "coming from a legitimate Android client".
From time to time we can update the secret (perhaps at each new version of the app).
If in future we will need confidentiality we will enable TLS for the relevant REST calls.
Do you think that this solution would work? Is anyone using something like this? Alternatives? Advices?
Thanks.
I am not a security expert.
Your solution sounds fine to protect you from "the random person", but you are still vulnerable to a dedicated attacker. Anything stored on the client can be dug out and used against you. ProGuard will dissuade a casual attacker, but against a dedicated attacker it's just a speed bump.
Nobody here is going to be able to tell you if that level of security is good enough, because it depends a lot on the specifics of your application. The final decision should rest with the product owner.
Starting to build an app where we will have a desktop and a mobile client applications. These two apps will exchange messages/info on frequent basis. The idea is not to have any server/central entity for this communication. We want to send/receive messages without any server implementation. I googled on these and got peerjs.com, openpeer.org and google project apprtc. Peerjs and apprtc are kind of web based applications which are not in our kind of.
But still it's not very clear on how this things works out as they involve any server or not. Kind of stuck and not sure where to start and how. Is it possible at all?
We are not yet tied to any platform, so open to any kind of implementation. Please share if you have any similar experiences of any applications using this kind of technical stack?
use webrtc ios project, and its what you need
https://github.com/gandg/webrtc-ios
Sockets is what I'd use, assuming the network requirements mentioned above
Those two devices may or may not be on the same network.
Then you need a server of some form, whether you want one or not. That server may simply be a data broker (see PeerJS) or provide more functionality, but it must exist. That server may be one that you host yourself or be some common cloud provider, but it must exist.
I have an android application. The application reads data from my server and displays them to the user.
Now, the question is: How to prevent someone from making a bogus app and asking my server to send data to this app?
This wastes both my bandwidth and makes use of my content while allowing people to create competitive apps using my data.
As you know, trying to prevent reverse engineering is like trying to stop piracy: impossible. Android reverse engineering especially it's like stealing candy from a baby.
Use API Tokens. Possible solutions:
HTTP Basic Auth example (only if you are using https)
Query Paramter (like https://example.com/resource?token=3786428762) (also only over https)
HMAC - sophisticated and more complex to implement, requires substainsial redesign of the backend communication, but the most secure
But mind you, either way you need to somehow hardcode a key/salt/hash/password in your app which can be reversed engineered one way or the other. There is no real (practical) possibility in Android to avoid rogue clients from accessing your backend (especially in rooted devices).
I would recommend HTTP Basic Auth since it's the best tradeoff in effort, usability and security (It's also used by the majority of public apis) It's very easy to implement since you only need to send a hardcoded http header, it's supported by practically every http server and it does not change your API and pollute it with query parameter and it's also reasonably secure if used over https.
Make the server require an API key and obfuscate the key in your code, see this answer: Best Practice for storing private API keys in Android
If you use http server, you can use http auth basic
Basic access auth
You could use something like reCAPTCHA to verify that the client is not a bot.
We have an android and ios app which sends data and commands to a server with http webservice. How can i prevent the possibility, that fake-clients also can send something to the server? How can I determine serversidely if the data/command really comes from our apps.
You cant really prevent it. There are several techniques to make it harder for people abusing your services.
A simple check can be to check the user agent calling your webservice. Another pretty common one is to use a simple authentication via user/password authentication on your webserver. The username and password will be embedded into your app.
If you have enough time you should think about using a combination of this two methods plus authentication with a embedded ssl certificate. You simply could add this to your project and if someone really want to abuse your service, he have to extract this certificate atleast form your application.
There are some other useful techniques but you cant prevent reverse engineering or network sniffing.
Sincerely,
fuxx
The most robust solution is not to try. Techniques like DasFuxx's answer suggests can make it faintly harder, but someone can always decompile your application and get whatever secrets you have embedded in it.
Instead, follow the rule of multiplayer game development:
Don't trust the client.
Don't think about your application as the user interface. Think about your network protocol/API as being the user interface; then design that interface so that it cannot be abused.
It may not be possible to do so completely, but insofar as you succeed, you have true security (rather than fighting the same losing battle as DRM systems).
I would implement oAuth. See the following link for more information on how to implement such a solution.
You can't. It's that simple...
I have an Android game and I want it to store data - say a high score for example - against each user on a server backend.
Here's a list of outrageously demanding requirements! It's unlikely any solution can meet all these demands, so I've changed/prioritised them:
Minimum/very easy server and client code
Free/cheap
Automatically scalable and no/little server maintenance
As secure as possible with minimum code
Seamless - no user action required to authorise/choose anything
I know about Parse, and that seems the easiest option but I'm concerned about the future cost and would prefer more control so I'd like some alternatives.
AWS seems a lot of effort, although it handles secure anonymous authentication fairly easily and well.
App Engine would be great if there was an easy way to secure requests without requiring the user to login or authorise app engine.
So... I want the seamlessness of Parse, the security of AWS, and the auto-scaling of App Engine. Also the ease of use/coding of Parse. Fingers Crossed. :)
Thanks
My advice: use Parse, but create enough abstraction/encapsulation in your models so that swapping Parse out for another service won't be so painful. But seriously, I don't think Parse will get expensive (or even not-free) until your app is seeing very high demand. Furthermore, the Parse guys seems pretty committed to openness: you can export your data as a CSV and they have a REST API so any type of program you write can access the data.
If you're determined to roll your own, I'd recommend creating a Rails back-end with Heroku. Piggyback SSL is free, HTTP Basic Auth is really easy in Rails, and the entire stack will play nicely with whatever db you'd want to use (I'm assuming NoSQL since you want flexibility).
Any PaaS that supports SSL and a dataabse will probably do. Estimate your traffic, data storage and processing needs and pick one that is cheap enough to get started. App Engine is going out of beta soon, and the pricing model will be changed, so if you want autoscaling you'll have to pay for it.
What exactly is 'secure anonymous authentication' and how does AWS support it?