Hi Less, Thanks again for your answer. It took me a few hours but I read the whole tutorial on the blog post and tried to work with it, including its link about Obtaining an access token (http://developer.android.com/google/auth/http-auth.html#obtain). If I leave the code as it is, it does require a google account to work. However since you told me it was possible to do this without this requirement, I tried to determine where is located the google account requirement in the code. My belief is that it is in the pickUserAccount() and more specifically on the use of newChooseAccountIntent. It seems like it is possible to provide it an Account object that could be my own login system, and thus in the end it would be possible to avoid google accounts.
However could you please confirm that's what you were talking about in your last post? Le mercredi 17 décembre 2014 19:34:25 UTC+1, Les Vogel a écrit : > > Kevin, > > The blog post > <http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html> > > allows things to work w/o you users logging in, it's just a bit complex. I > would strongly suggest you look at that. > > On Wed, Dec 17, 2014 at 4:26 AM, Gannicus <kevin.k...@gmail.com > <javascript:>> wrote: >> >> 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 <le...@google.com> 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 <kevin.k...@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-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 >>>> >>> >>> >>> >>> -- >>> 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-appengi...@googlegroups.com <javascript:>. >> To post to this group, send email to google-a...@googlegroups.com >> <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 | le...@google.com <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 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.
