title: How To Secure Web Service Without Login
body: <p>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) and GETs the nearest 25 markers to display on a map.</p>
  
  <p>It's a very trivial app and I cannot imagine anyone putting great effort into abusing the web service. However, I can see there is fun for someone in POSTing many markers. What most concerns me is someone running a script that pushes many requests (using expensive bandwidth and making nonsense of my app data).</p>
  
  <p>I am slowly reaching the conclusion this cannot be secure. The best answer is "do not do this". Do not provide a web service without authentication. Not many services are so open. Google's You Tube API is open but most are not. Unfortunately, I have no choice. So after days of looking at this here's my thinking. Be aware I am very far from a security expert and I am confident my approach could be improved upon. But it might point you in the right direction. Hopefully, someone more experienced might chime in and correct/improve upon this. I found <a href="http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/">this article</a> and comments particularly helpful.</p>
  
  <p><strong>Message Level Security</strong></p>
  
  <p>I will secure the msgs with a hash encryption. The clients and web service all retain a copy of a shared secret which is used as a salt to create a hash from the URL and all the POST arguments. The hash is passed as an additional argument and the hash is rebuilt and compared at the other end (using the shared key as a salt). This is pretty good until you understand that any mobile client code can be reverse engineered in minutes. At which point this line of defense is utterly useless.</p>
  
  <p><strong>Client Measures</strong></p>
  
  <p>The client includes rate limiting of messages as a measure to restrict the number of messages sent by honest users. Yet again this is useless against an attacker who jailbreaks the mobile device.</p>
  
  <p><strong>Server Side Security</strong></p>
  
  <p>So the server side must have as much additional security measures as possible, to stand alone on the assumption that your client (and shared secret) is compromised. Here is what I have:</p>
  
  <p>One msg arg is a UTC time which is used to limit replay attacks. This should prevent an attacker from firing the same msg at the server repeatedly.</p>
  
  <p>The server performs rate limiting by IP. Yes, IPs are easily spoofed and proxy switching is childs play but everything helps when you have so little.</p>
  
  <p>Of course, the server strictly validates all arguments, uses parametised queries and doesn't return exceptions.</p>
  
  <p><strong>Transport Level Security</strong></p>
  
  <p>Unfortunately, I am fairly confident that issuing individual client SSL certs is not possible without a registration process. And because I am using the msg hash check (and my data is not private) I am not entirely sure what SSL brings to the table. However, I will probably use SSL (with one app wide cert) because it adds another level of security that is easily and cheaply deployed (albeit at a cost of additional connection time for every msg).</p>
  
  <p><strong>The Gaping Great Big Hole In My Approach</strong></p>
  
  <p>I am warned that should the app become popular that someone will compromise the shared secret on the client. Just because they can and they will probably post it on the internet. So really it all comes down to the server side. Unfortunately, <em>I have no way to identify and block an attacker</em>. This I would dearly love. </p>
  
  <p><strong>A Final Plea</strong></p>
  
  <p>After days of research this is all I have. But I want more. I would particularly appreciate any ideas to beef up the server side. So, I have put all my SO points up as a bounty. Yes sir, all 97 points! </p>