How To Secure Web Service Without Login

Question

I have a mobile app (currently IOS and soon Android) which talks to a web service. There is no login and the data is not private. Basically, the app POSTs a marker (lon, lat

Answer 1

It is tricky, you don't expect anybody to tamper the data ... so your concern is not about integrity. And since you do not maintain any list of clients ... there cannot be any concern about Authenticity?

And for all the well know Webservice attacks (like DoS or replay attacks) you get firewalls that can prevent them. So I don't think you need to bother about them much.

But then you you don't want to send plain text data and want to make sure that your download app is what is pushing the data.

If you look at the approaches you are evaluating :

Secured Key : As I understand the server and the App are going to share the same Key and if I am correct all the apps on all the devices will share the same Key. And when the app pushes the data it hashes the Actual feed and sends across Actual feed + the hashed feed. On the server side you would use the Key and hash the actual feed and verify if it is matching with the hashed feed. And in my opinion this solution is mainly addresses the Data integrity aspect which is not a major concern for you. rgt! (And yes it will probably be easy to reverse engineer.)

In the above approaches server would need to store the Key So if your Key is compromised your whole service will be and it will be difficult to update all the apps with new key. Or else if the app generates a Key it will have to send the key on the wire along with the message as digest or something(like timestamp + some random number). Not so difficult to break.

Certificate: Even with certificates you get the same security .. but it is difficult to break but easy to steel :). If you are keeping a private Key with device (ofcourse then you will have to maintain a public key at the server). You will have to assign a private key per client and then the server needs to maintain the public key for all private keys assigned. If a private key is compromized only that single app can be red flaged and requested for an update.

So what is left is from an application development perspective you want to avoid fabricated data. For sake of preventing mischief The the only point to check such things is in the application logic. You will need to cache the last ten(or what even the optimum number is) feeds (comming from same IP)and have some sort of logic verify if there is a flaw.