Security is a lot of things to a lot of people. For this, we can think about it as raising the cost for your adversary, while trying to stay within your cost of development (skill, experience, time to market, etc.) A determined, well funded adversary can usually bypass / break most security systems. There are lots of papers on this available on the net -- search for "security cost benefit analysis"
You know your app, and what you are trying to secure, so, it's really up to you to decide what is the appropriate method to secure your api. I'm trying to suggest a range of things, they each have different cost / benefits. The constant token method is fairly simple, and as you pointed out, vulnerable to a decompilation attack. You can improve it by replacing the using of a single constant that can be easily found by decompiling the code, uses several values that must be sent through a formula to get the correct token value. Google Endpoints used with Google accounts (including Google for Business / Education / Government accounts) provides good security easily -- it didn't sound like this met your needs. We have the Google Identity Toolkit <https://developers.google.com/identity-toolkit/>, which will allow you to securely login your users, it also supports Google, Yahoo, AOL, Microsoft, Facebook, and Paypal logins as well as your own. In the Abelana-gcp <https://github.com/GoogleCloudPlatform/abelana-gcp> and Abelana-android <https://github.com/GoogleCloudPlatform/abelana-android> apps, I used the Identity Toolkit for user identity, then rolled by own access tokens that I used for all but one api (the login one). (My understanding is that direct support for access tokens is coming) The code is in Go for AppEngine and Java for the Android app. You might also take a method used for XCRF prevention that involves encrypting a random # and a expiration time on the first server reply, then requiring that value to be passed on all subsequent requests. It's a bit more work and requires storing the value on the server side. The last suggestion I gave had a link for verifying a certificate -- looking at it today it appears that AppEngine is providing id to your client, not the other way around. I'll look around to see if there is a way to ask TLS to bring the client certificate info to the API. But as I said before, in the end, you need to make the tradeoff between UX / ease of development and security -- it's not an easy one. The best security mechanisms involve cryptography, your protected by math. It's tricky and difficult to get right, and really requires audits by folks who know what they are doing if you want to really protect something valuable. I've found the works of Bruce Schneier to be invaluable. I suggest Cryptography Engineering: Design Principles and Practical Applications (which replaces Practical Cryptography) and Beyond Fear: Thinking Sensibly About Security in an Uncertain World. On Mon, Dec 15, 2014 at 4:24 AM, Gannicus <kevin.kaido...@gmail.com> wrote: > Thank you very much Les. So I should focus on the solution "you could > either pass a unique key known to your apps along with each call"? > However, I heard it is possible to decompile an Android app from the .apk. > If that's true, that solution would be risky right? > > Le lundi 15 décembre 2014 07:21:35 UTC+1, Les Vogel a écrit : >> >> Hi Kevin, >> >> The first suggestion is the same as Dan gave on SO at the end. I would >> suggest you use that to begin with, especially since your beginning. >> >> Les >> >> On Sun, Dec 14, 2014 at 3:12 PM, Gannicus <kevin.k...@gmail.com> wrote: >> >>> Thank you for your answers. Here is the thread where I read about google >>> accounts restrictions: http://stackoverflow.com/questions/ >>> 19786339/google-cloud-endpoints-limitations-any-proposed-solutions >>> >>> Anyway, Les Vogel confirmed that users have to get a Google account to >>> use the OAuth authentification (which is a shame in my opinion...). >>> Hopefully your solutions are not too hard to implement Les Vogel, I don't >>> have that much experience in web applications. >>> >>> Le dimanche 14 décembre 2014 20:26:24 UTC+1, Chad Vincent a écrit : >>> >>>> 1) If your signing key is compromised, then someone with that >>>> information would be able to make calls by spoofing the client signature >>>> from your app. >>>> >>>> 2) Based on the documentation, it looks like no, but without knowing >>>> what was said in the SO thread, I wouldn't put money on it one way or the >>>> other. >>>> >>>> On Sunday, December 14, 2014 10:27:51 AM UTC-6, Gannicus wrote: >>>>> >>>>> Hello, >>>>> >>>>> I am using Cloud Endpoints with Java to create my API and I would like >>>>> to be used only by my android client application. >>>>> I read the Google documentation and it seems like I have to generate >>>>> an ID thanks to the SHA1 fingerprint. >>>>> >>>>> However I would like to have a confirmation on this: >>>>> >>>>> 1) Does it really restrict API calls to my android client only? I >>>>> don't want any possibility to call it thanks to a REST client, a browser >>>>> or >>>>> something like that. >>>>> >>>>> 2) Some part I didn't understand -I read something about it on Stack >>>>> Overflow- : do the users have to own a google account to use my android >>>>> client then? >>>>> >>>>> Thank you. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Google App Engine" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to google-appengi...@googlegroups.com. >>> To post to this group, send email to google-a...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/google-appengine. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Les Vogel | Cloud Developer Relations | le...@google.com | 408-676-7023 >> > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-appengine+unsubscr...@googlegroups.com. > To post to this group, send email to google-appengine@googlegroups.com. > Visit this group at http://groups.google.com/group/google-appengine. > For more options, visit https://groups.google.com/d/optout. > -- Les Vogel | Cloud Developer Relations | l...@google.com | 408-676-7023 -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
