Re: [google-appengine] Re: Private API with Cloud Endpoints

[Gannicus]

Hi Les,

Thank you, I emailed you my code like you said. I did get my client ID 
thanks to the console, I also created a consent screen but I can't manage 
to get a token.

Le vendredi 19 décembre 2014 00:08:29 UTC+1, Les Vogel a écrit :
>
> Hi Kevin,
>
> Not sure why you  are calling *pickUserAccount*() or the 
> *newChooseAccountIntent* as your use case shouldn't either of those.  
> Please take a look at this paragraph.
>
> You’ll need to call the Google Play services GoogleAuthUtil 
> 
>  class 
> to get an ID token; the procedure is as described inObtaining an Access 
> Token . 
> There’s one extra bit of magic: the value of the scope argument to the 
> getToken(email, 
> scope) method. It has to be the string *audience:server:client_id:X*, 
> where X is the Client ID of for the Web app, as described above. If our 
> Client ID were the example value given above, the value of the scope 
> argument would 
> be*audience:server:client_id:9414861317621.apps.googleusercontent.com 
> *.
> I've highlighted what you need to do.  You get a client id from 
> cloud.google.com/console  click on your project, then API's and Auth, 
> then create a client ID for an Android Application, if you don't already 
> have one, using the instructions in the blog post.  You may find things 
> work better if you also create a Consent screen, that shouldn't be 
> necessary, but I've seen occasions where I get a better result by doing so.
>
>
>
> On Thu, Dec 18, 2014 at 1:04 PM, Les Vogel 
> > wrote:
>>
>> Hi Kevin,
>>
>> I'll write a longer answer shortly, however, if you could send me 
>> lesv@g...  your code, I'll take a peek.
>>
>> On Thu, Dec 18, 2014 at 9:52 AM, Gannicus > > wrote:
>>>
>>> Hi Les,
>>>
>>> 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 
 
  
 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  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 
> , 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-bac
>> k-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  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 

Re: [google-appengine] Re: Private API with Cloud Endpoints

['Les Vogel' via Google App Engine]

Hi Kevin,

Not sure why you  are calling *pickUserAccount*() or the
*newChooseAccountIntent* as your use case shouldn't either of those.
Please take a look at this paragraph.

You’ll need to call the Google Play services GoogleAuthUtil
 class to get an ID token; the
procedure is as described inObtaining an Access Token
.
There’s one extra bit of magic: the value of the scope argument to the
getToken(email,
scope) method. It has to be the string *audience:server:client_id:X*, where
X is the Client ID of for the Web app, as described above. If our Client ID
were the example value given above, the value of the scope argument
would be*audience:server:client_id:9414861317621.apps.googleusercontent.com
*.
I've highlighted what you need to do.  You get a client id from
cloud.google.com/console  click on your project, then API's and Auth, then
create a client ID for an Android Application, if you don't already have
one, using the instructions in the blog post.  You may find things work
better if you also create a Consent screen, that shouldn't be necessary,
but I've seen occasions where I get a better result by doing so.



On Thu, Dec 18, 2014 at 1:04 PM, Les Vogel  wrote:
>
> Hi Kevin,
>
> I'll write a longer answer shortly, however, if you could send me lesv@g...
>  your code, I'll take a peek.
>
> On Thu, Dec 18, 2014 at 9:52 AM, Gannicus 
> wrote:
>>
>> Hi Les,
>>
>> 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
>>> 
>>> 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  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
 , 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-bac
> k-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  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 appro

Re: [google-appengine] Re: Private API with Cloud Endpoints

['Les Vogel' via Google App Engine]

Hi Kevin,

I'll write a longer answer shortly, however, if you could send me lesv@g...
 your code, I'll take a peek.

On Thu, Dec 18, 2014 at 9:52 AM, Gannicus  wrote:
>
> Hi Les,
>
> 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
>> 
>> 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  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
>>> , 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-bac
 k-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  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
> , 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  and
> 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 fir

Re: [google-appengine] Re: Private API with Cloud Endpoints

[Gannicus]

Hi Les,

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 
> 
>  
> 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  > 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 
>> , 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  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 
 , 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  and 
 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 

Re: [google-appengine] Re: Private API with Cloud Endpoints

[Gannicus]

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 
> 
>  
> 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  > 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 
>> , 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  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 
 , 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  and 
 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

Re: [google-appengine] Re: Private API with Cloud Endpoints

['Les Vogel' via Google App Engine]

Kevin,

The blog post

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  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
> , 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  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
>>> , 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  and
>>> 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  wrote:
>>>
 Thank you very much Les. So I should focus on the solution "you could
 either pass a unique key known to your apps al

Re: [google-appengine] Re: Private API with Cloud Endpoints

[Gannicus]

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 
, 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  > 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 
>> , 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  and 
>> 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 > > 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 su

Re: [google-appengine] Re: Private API with Cloud Endpoints

['Les Vogel' via Google App Engine]

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  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
> , 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  and
> 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 
> 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  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 th

Re: [google-appengine] Re: Private API with Cloud Endpoints

['Les Vogel' via Google App Engine]

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
, 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
 and 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  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  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 wa

Re: [google-appengine] Re: Private API with Cloud Endpoints

[Gannicus]

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  > 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.

Re: [google-appengine] Re: Private API with Cloud Endpoints

['Les Vogel' via Google App Engine]

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  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-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.

[google-appengine] Re: Private API with Cloud Endpoints

[Gannicus]

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-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.

[google-appengine] Re: Private API with Cloud Endpoints

[Chad Vincent]

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-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.