I have a public REST API that I want to protect. I've read about HTTP basic authentication, OAuth, APIs Key ... but as far as I know, this methods require registration (username and password). I want that the users (Android apps) of my service can use it without registration and login.
So, ideally, I want that only Android apps can use the service and I would like to control the usage of the service. I've thought about get something unique about Android devices but I think it is easily falsificable.
The reason for no registration is that the service is very simple (check out the bus arrivals, and participate sending some time arrivals) and I think is overkill that users have to provide a username/password for such a simple service.
How I can achieve this?
I want that only Android apps can use the service... How I can achieve this?
You can't.
You can try to casually reduce the number of things other than Android apps that can use your service (e.g., have your app use a custom user agent header in the HTTP requests, and use SSL). However, people who are determined to get past that will be able to do so, by reverse-engineering your app, or sniffing on the HTTP traffic.
Related
Is there any mail sending api/service for android applications apart from Java mail API?
Right now I am using javamail API and after testing it I thought its working fine but actually its getting blocked when used from some other network despite of allowing access for less secured apps in Gmail setting of that particular account.
I don't mind even if some paid service is available for few bucks.
This is not required for bulk mails. Required for functionality like feedback of app.(I don't want to use firebase and all because there is no mechanism for login in my app)
Thanks
It's a bad idea to embed mail server credentials in your app, it's too easy to abuse them. Better to create a web service to accept the feedback and then use JavaMail on the server to send it, if you still even need email. You can limit the functionality of the web service to make it harder to abuse.
I have a full application API written in node.js with Express.. Now, the API should be only accessed from my Android application, how can I protect the node app from outside requests?
If I use some kind of a password protection, I'll have to write that password in my android app and since the application is available to everyone, the password can be easily found.. What is the solution to this kind of situations?
Web based security can be a bit tricky sometimes, but if you have an app you could use a token-base approach.
When your application starts, it can request a token from your API, which then must be present in all other requests to your API.
Did a quick search for this kind of thing and came upon this page, which might be worth a look: http://thejackalofjavascript.com/architecting-a-restful-node-js-app/
I'm busy building an app for android. When it's properly received by Android users I would like to expand to iOS.
But, before we get there, I first want to make the right choice. So my question, what to do?:
writing all the logic inside the app and use Cognito (https://blogs.aws.amazon.com/security/post/Tx3LP54JOGBE0AY/Building-an-App-using-Amazon-Cognito-and-an-OpenID-Connect-Identity-Provider) to access the data from DynamoDB
or let my app connect with my own API which handles the validation rules, which I then connect with DynamoDB database (don't know or API -> Cognito -> DynamoDB is a better solution, didn't really used it yet so...).
Now we all know about those issues where hackers built ways to bypass certain validation rules (as far as I read, most commonly by decompiling the app). I really want to avoid that!
So what do you experienced Android developers use? I know the answer seems obvious. But the reason I ask this is because I would like to avoid having my infrastructure, which I need to update etc. But to be able to register users, without the need of an third party which supports OpenID like twitter, facebook or Google, AND secure my validation rules, it seems like I have no choice. Or do I?
If you are targeting multiple platforms, it's usually best to conduct the majority of your business logic in an api outside of the app. It reduces code duplication and if validation is done at the api level, it limits the ability of malicious users to bypass validation rules.
With that said, running your own api doesn't necessarily require running your own infrastructure. Two AWS web services that could help are Amazon API Gateway and AWS Lambda. Registering your users can be done using Amazon Cognito Your User Pools.
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.
What is the best solution to secure a REST service provider (assume a java servlet running on google appengine) by allowing requests only from iOS or Android device from a specific app?
Assume I have a servlet running on google appengine that does some processing and responds to a GET request with some JSON data. And I want to restrict this access to my app that runs on Android and iOS.
My current solutions are:
Use if(tokenValue ==
request.getHeader(tokenKey)) on the
appengine servlet. And
response.addHeader(tokenKey,
tokenValue) on the mobile apps'
code. So basically only my app would
know the token key.
Use HTTP(s) for the above solution, appengine supports this
Use oAuth - but I need to have the user sign-on to some oAuth provider from the app, which complicates the app
Suggest other useful approaches to tackle this problem. Assume this servlet only serves GET requests and maybe use Restlet or Jackson
Only 3 would be an appropriate solution if security is important to you. This is because anyone using the application can intercept the traffic and just replay the values against your web service. SSL offers some protection but a good attacker can work out how to capture data if they control the device. With OAuth the damage done by an attacker is limited to a single user (as long as they are not an app admin).
How about using a client SSL certificate? I haven't tried this, but I'm considering it. Here's a page that describes the approach, with some sample code:
http://blog.crazybob.org/2010/02/android-trusting-ssl-certificates.html