Hi Les, First of all thank you very much for your answers and your help. Like you said, security depends on how much time/money... I want to spend. For now as a beginner I just want to use a minimal protection. I will start things off by studying your links about @clientsIds and @Audiences.
However the first link (http://android-developers.blogspot.fr/2013/01/verifying-back-end-calls-from-android.html) mentions Google accounts: "It turns out that Google Play services <http://developer.android.com/google/play-services/index.html>, now available on every compatible device running Android release 2.2 or higher, offers a good solution to this problem, based on the use of Google Accounts", Hopefully it's not necessary to ask my users for their google accounts. I will try it anyway, or else I will just create my own token system. Le mardi 16 décembre 2014 00:11:23 UTC+1, Les Vogel a écrit : > > Hi Kevin, > > I was reminded of the following today: > http://android-developers.blogspot.com/2013/01/ > verifying-back-end-calls-from-android.html > > In cloud endpoints, you can use @clientIds and @audiences to whitelist > your client ids. > https://cloud.google.com/appengine/docs/java/endpoints/auth > > It should lock things down for you. > > Les > > On Mon, Dec 15, 2014 at 10:58 AM, Les Vogel <[email protected] > <javascript:>> wrote: > >> 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 <[email protected] >> <javascript:>> 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 <[email protected]> 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 [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> 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 | [email protected] | 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 [email protected] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> 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 | [email protected] <javascript:> | >> 408-676-7023 >> > > > > -- > Les Vogel | Cloud Developer Relations | [email protected] <javascript:> | > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
