Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on a website for which I hope to have an application for as well. Because of this, I am creating PHP API's which will go into my Database and serve specific data based on the method/function called.

I want to protect these API's from misuse however, and I plan on implementing Authentication Digest to do so. However one of the OS's I want to support is Android. And I know that a malicious user would be able to reverse engineer the Android app and figure out my authentication scheme.

I am left wondering:

  1. Is there a better way to protect these API's from misuse?
  2. Is there a way to prevent a malicious user from reverse engineering the app and potentially seeing the source code for it, enabling them to see my authentication scheme?
  3. If none of these are preventable, then is my only option to have a Username/Password cred specifically for the Android app, and when eventually hacked, change the creds and issue an update for the app?
share|improve this question
Wait, so your going to have one username/password for all users and not one per user? If so, why? To prevent misuse, right - but if anyone can download the app anyway what misuse exactly are you trying to prevent? – James Jun 5 '12 at 23:42
I was (and even still, am) lacking a lot of experience in this field of security. My main concern was with someone hacking the Android app, and figuring out how to make "authentic" posts to my db. I guess I've come to terms that there isn't really a way to prevent it. Or maybe there is but I don't have the experience nor resources to implement it. The best that I could come up with was implement a unique hash of each user's un/pass inside the authenticate request, then authenticate server side with their password. At least this way I can track if any user has made malicious requests. – edc598 May 17 '13 at 16:34

In my opinion, talking about authentication, you could give a look to OAuth |

I've recently implemented a RESTful service (using other techs, .NET/NancyFX). In my case the mobile app needs access to public available content (the same published in companion website). In a case like mine the real concern wasn't security but some sort of misuse.

I've protected my service using an API Key:{api-key}/xyz. Valid keys are stored in a persistent repository (in my case a mysql instance) and checked on every request. This worked great for me.

You may also find this useful too |

share|improve this answer
just don't bother with OAuth 2.0 :… – gbjbaanb Aug 4 '12 at 18:19
OAuth 2.0 perhaps not, but all authentication schemes get convuluted in very-very-very short time (SAML, WS-*, HTTP, they ALL wanted to be simpler than their predecessors, and all of them were marketed this way). OAuth 1 is easy and logical – Aadaam Aug 5 '12 at 0:20
Yea I looked into OAuth. Like gbjbaanb pointed out with his link, I found implementing it a little beyond my abilities. I like your idea about using an API Key. I'll look into that a little more. I assume this would make it easier to block someone from using my services should I find any evidence of misuse? – edc598 May 17 '13 at 16:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.