Brief introduction of what I am trying to accomplish. I am attempting to use the Resource Owner Password Credentials Grant. The reasoning being that I do not want any limited experience to the end user for our applications. They must have a full in-app experience without interruption.
My concerns: Using dynamic registration seems to be worthless. If a public end user can register any user any time they want if they get the username and password, then the registration stopped nothing. The whole point of client registration is so that only that client may have access.
My solution: 1) A resource owner downloads the application 2) The resource owner enters their username and password credentials into the client form 3) The username and password are kept only in memory during the following process and is dropped when the registration is complete 4) The phone application is compiled with a registration identifier. This is used in registration requests as a mechanism to prevent public registrations. 5) Registration is made against an endpoint over SSL passing the registration identifier, resource owner username and password. 6) The client receives a client_id and client_secret. The client_id is the username, and the client_secret is a cryptography random key locked to the username (client_id). 6a) If a client_secret exists for this user, it will be returned, no new key will be generated. 7) Registration is complete, from here on out it is standard resource owner password credentials
Notes The client_secret will be stored in a cryptography keystore local on the phone. New devices added for that user will have the same. The whole point of this is to prevent public registrations, such as if someone makes a wanna-be phone app that looks like ours.
Is it even important to prevent public registrations? I am just very weary about supporting dynamic registration, I would prefer a single website where people register for API use out-of-band. But since mobile apps are easily rootable, this is my attempt to close some gaps.
Questions? Comments? All input, good, bad, or neutral are welcome.
It doesn't seem like your solution prevents "public registrations" at all.
Your "registration identifier" becomes public the moment the first user
downloads your app, and could turn around and publish their own app that
uses the same registration identifier.
On Monday, July 23, 2012, Brad Laney wrote:
> Brief introduction of what I am trying to accomplish. I am attempting to
> use the Resource Owner Password Credentials Grant. The reasoning being that
> I do not want any limited experience to the end user for our applications.
> They must have a full in-app experience without interruption.
> My concerns:
> Using dynamic registration seems to be worthless. If a public end user can
> register any user any time they want if they get the username and password,
> then the registration stopped nothing. The whole point of client
> registration is so that only that client may have access.
> My solution:
> 1) A resource owner downloads the application
> 2) The resource owner enters their username and password credentials into
> the client form
> 3) The username and password are kept only in memory during
> the following process and is dropped when the registration is complete
> 4) The phone application is compiled with a registration identifier. This
> is used in registration requests as a mechanism to prevent public
> registrations.
> 5) Registration is made against an endpoint over SSL passing the
> registration identifier, resource owner username and password.
> 6) The client receives a client_id and client_secret. The client_id is the
> username, and the client_secret is a cryptography random key locked to the
> username (client_id).
> 6a) If a client_secret exists for this user, it will be returned, no new
> key will be generated.
> 7) Registration is complete, from here on out it is standard resource
> owner password credentials
> Notes
> The client_secret will be stored in a cryptography keystore local on the
> phone. New devices added for that user will have the same.
> The whole point of this is to prevent public registrations, such as if
> someone makes a wanna-be phone app that looks like ours.
> Is it even important to prevent public registrations? I am just very weary
> about supporting dynamic registration, I would prefer a single website
> where people register for API use out-of-band. But since mobile apps are
> easily rootable, this is my attempt to close some gaps.
> Questions? Comments? All input, good, bad, or neutral are welcome.
> --
> You received this message because you are subscribed to the Google Groups
> "DotNetOpenAuth" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/dotnetopenid/-/Ylrw63Yn15wJ.
> To post to this group, send email to dotnetopenid@googlegroups.com<javascript:_e({}, 'cvml', 'dotnetopenid@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
> 'dotnetopenid%2Bunsubscribe@googlegroups.com');>.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
-- --
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
Yes, that's true. If they manage to decompile an obfuscated mobile app, then yes they could find the password.
What else am I supposed to do? This is the best thing I could come up with. Even if I used private certificate that could be taken off the phone as well.
In a previous post I thought this is what you mentioned to do, with dynamic registration. I thought what's the point of dynamic registration if anyone can do it. So I tried to put in a solution to prevent people from being able to do public registrations.
On Monday, July 23, 2012 2:15:41 PM UTC-5, Brad Laney wrote:
> Brief introduction of what I am trying to accomplish. I am attempting to > use the Resource Owner Password Credentials Grant. The reasoning being that > I do not want any limited experience to the end user for our applications. > They must have a full in-app experience without interruption.
> My concerns: > Using dynamic registration seems to be worthless. If a public end user can > register any user any time they want if they get the username and password, > then the registration stopped nothing. The whole point of client > registration is so that only that client may have access.
> My solution: > 1) A resource owner downloads the application > 2) The resource owner enters their username and password credentials into > the client form > 3) The username and password are kept only in memory during > the following process and is dropped when the registration is complete > 4) The phone application is compiled with a registration identifier. This > is used in registration requests as a mechanism to prevent public > registrations. > 5) Registration is made against an endpoint over SSL passing the > registration identifier, resource owner username and password. > 6) The client receives a client_id and client_secret. The client_id is the > username, and the client_secret is a cryptography random key locked to the > username (client_id). > 6a) If a client_secret exists for this user, it will be returned, no new > key will be generated. > 7) Registration is complete, from here on out it is standard resource > owner password credentials
> Notes > The client_secret will be stored in a cryptography keystore local on the > phone. New devices added for that user will have the same. > The whole point of this is to prevent public registrations, such as if > someone makes a wanna-be phone app that looks like ours.
> Is it even important to prevent public registrations? I am just very weary > about supporting dynamic registration, I would prefer a single website > where people register for API use out-of-band. But since mobile apps are > easily rootable, this is my attempt to close some gaps.
> Questions? Comments? All input, good, bad, or neutral are welcome.
You should assume that decompiling an obfuscated app is quite doable. What
with the arms race for apps like iTunes, you know that not even Apple,
whose major income depends on the DRM it applies to music, can't avoid
having its encryptions cracked since ultimately the ability to decrypt is
inside the client just waiting to be discovered.
What I meant by dynamic registration is that an anonymous client can become
confidential -- not trusted, simply confidential. This means you don't
really know what app is on the client, but at least you know on a
subsequent call that it's the *same* client that had registered previously.
This is enough security to protect OAuth 2 tokens, but only you can decide
whether that's enough to protect the user's data and your server resources.
Ultimately, the only way to prevent others from being able to tamper with
your app or create a look-alike is to not use a client app at all, but
rather keep your app as a web site, where a client secret can be securely
stored, and accept that anyone can create local clients that even drive
that web site. After all, that's what all browsers themselves do.
It comes down to what you're protecting. Your income perhaps, which can
come from selling the app itself and selling a subscription to your online
service, and you're probably protecting some user data. The online service
and user data are all on the server, so that's something that OAuth 2 can
protect. Your app can be protected by the mobile app store(s). But other
folks can create look-alikes, and the only way to prevent that is through
legal action.
On Tuesday, July 24, 2012, Brad Laney wrote:
> Yes, that's true. If they manage to decompile an obfuscated mobile app,
> then yes they could find the password.
> What else am I supposed to do? This is the best thing I could come up with.
> Even if I used private certificate that could be taken off the phone as
> well.
> In a previous post I thought this is what you mentioned to do, with
> dynamic registration. I thought what's the point of dynamic registration if
> anyone can do it. So I tried to put in a solution to prevent people from
> being able to do public registrations.
> On Monday, July 23, 2012 2:15:41 PM UTC-5, Brad Laney wrote:
>> Brief introduction of what I am trying to accomplish. I am attempting to
>> use the Resource Owner Password Credentials Grant. The reasoning being that
>> I do not want any limited experience to the end user for our applications.
>> They must have a full in-app experience without interruption.
>> My concerns:
>> Using dynamic registration seems to be worthless. If a public end user
>> can register any user any time they want if they get the username and
>> password, then the registration stopped nothing. The whole point of client
>> registration is so that only that client may have access.
>> My solution:
>> 1) A resource owner downloads the application
>> 2) The resource owner enters their username and password credentials into
>> the client form
>> 3) The username and password are kept only in memory during
>> the following process and is dropped when the registration is complete
>> 4) The phone application is compiled with a registration identifier. This
>> is used in registration requests as a mechanism to prevent public
>> registrations.
>> 5) Registration is made against an endpoint over SSL passing the
>> registration identifier, resource owner username and password.
>> 6) The client receives a client_id and client_secret. The client_id is
>> the username, and the client_secret is a cryptography random key locked to
>> the username (client_id).
>> 6a) If a client_secret exists for this user, it will be returned, no new
>> key will be generated.
>> 7) Registration is complete, from here on out it is standard resource
>> owner password credentials
>> Notes
>> The client_secret will be stored in a cryptography keystore local on the
>> phone. New devices added for that user will have the same.
>> The whole point of this is to prevent public registrations, such as if
>> someone makes a wanna-be phone app that looks like ours.
>> Is it even important to prevent public registrations? I am just very
>> weary about supporting dynamic registration, I would prefer a single
>> website where people register for API use out-of-band. But since mobile
>> apps are easily rootable, this is my attempt to close some gaps.
>> Questions? Comments? All input, good, bad, or neutral are welcome.
> --
> You received this message because you are subscribed to the Google Groups
> "DotNetOpenAuth" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/dotnetopenid/-/gvTXeUWDy9wJ.
> To post to this group, send email to dotnetopenid@googlegroups.com<javascript:_e({}, 'cvml', 'dotnetopenid@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
> 'dotnetopenid%2Bunsubscribe@googlegroups.com');>.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
-- --
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
Thanks. I forwarded your opinions (I share them) to my team, but I lost the
battle! We are going to include the "application id" (the id in the app)
for at minimum, logging purposes. But I made it fairly clear to them that
the application is still to be considered not trusted, and only
confidential. This also gives us the ability to invalidate all client
registrations and tokens based on the application id.
The idea is that if ABC Company uses us and wants to make a non-trusted
app, we give them an application id and they use that for dynamic
registration. If for some reason they break our usability rules and we want
to prevent them from getting keys, we can expire their application ID and
they can no longer register.
So it became more of a non-malicious user tracking code, than a secure one.
I just made it very clear that we cannot rely on it to give us security.
Thanks for all the helpful feedback, it's really refreshing to actually get
active support on some open source software for once.
P.S. I tried to advocate for using true OAuth2 Authorization Code Grants
but I couldn't convince anyone else that it's a good idea to do over the
usability of an in-app registration. They don't even want third parties to
have to open a webview :/
On Tue, Jul 24, 2012 at 11:57 AM, Andrew Arnott <andrewarn...@gmail.com>wrote:
> You should assume that decompiling an obfuscated app is quite doable.
> What with the arms race for apps like iTunes, you know that not even
> Apple, whose major income depends on the DRM it applies to music, can't
> avoid having its encryptions cracked since ultimately the ability to
> decrypt is inside the client just waiting to be discovered.
> What I meant by dynamic registration is that an anonymous client can
> become confidential -- not trusted, simply confidential. This means you
> don't really know what app is on the client, but at least you know on a
> subsequent call that it's the *same* client that had registered
> previously. This is enough security to protect OAuth 2 tokens, but only
> you can decide whether that's enough to protect the user's data and your
> server resources.
> Ultimately, the only way to prevent others from being able to tamper with
> your app or create a look-alike is to not use a client app at all, but
> rather keep your app as a web site, where a client secret can be securely
> stored, and accept that anyone can create local clients that even drive
> that web site. After all, that's what all browsers themselves do.
> It comes down to what you're protecting. Your income perhaps, which can
> come from selling the app itself and selling a subscription to your online
> service, and you're probably protecting some user data. The online service
> and user data are all on the server, so that's something that OAuth 2 can
> protect. Your app can be protected by the mobile app store(s). But other
> folks can create look-alikes, and the only way to prevent that is through
> legal action.
> On Tuesday, July 24, 2012, Brad Laney wrote:
>> Yes, that's true. If they manage to decompile an obfuscated mobile app,
>> then yes they could find the password.
>> What else am I supposed to do? This is the best thing I could come up
>> with.
>> Even if I used private certificate that could be taken off the phone as
>> well.
>> In a previous post I thought this is what you mentioned to do, with
>> dynamic registration. I thought what's the point of dynamic registration if
>> anyone can do it. So I tried to put in a solution to prevent people from
>> being able to do public registrations.
>> On Monday, July 23, 2012 2:15:41 PM UTC-5, Brad Laney wrote:
>>> Brief introduction of what I am trying to accomplish. I am attempting to
>>> use the Resource Owner Password Credentials Grant. The reasoning being that
>>> I do not want any limited experience to the end user for our applications.
>>> They must have a full in-app experience without interruption.
>>> My concerns:
>>> Using dynamic registration seems to be worthless. If a public end user
>>> can register any user any time they want if they get the username and
>>> password, then the registration stopped nothing. The whole point of client
>>> registration is so that only that client may have access.
>>> My solution:
>>> 1) A resource owner downloads the application
>>> 2) The resource owner enters their username and password credentials
>>> into the client form
>>> 3) The username and password are kept only in memory during
>>> the following process and is dropped when the registration is complete
>>> 4) The phone application is compiled with a registration identifier.
>>> This is used in registration requests as a mechanism to prevent public
>>> registrations.
>>> 5) Registration is made against an endpoint over SSL passing the
>>> registration identifier, resource owner username and password.
>>> 6) The client receives a client_id and client_secret. The client_id is
>>> the username, and the client_secret is a cryptography random key locked to
>>> the username (client_id).
>>> 6a) If a client_secret exists for this user, it will be returned, no new
>>> key will be generated.
>>> 7) Registration is complete, from here on out it is standard resource
>>> owner password credentials
>>> Notes
>>> The client_secret will be stored in a cryptography keystore local on the
>>> phone. New devices added for that user will have the same.
>>> The whole point of this is to prevent public registrations, such as if
>>> someone makes a wanna-be phone app that looks like ours.
>>> Is it even important to prevent public registrations? I am just very
>>> weary about supporting dynamic registration, I would prefer a single
>>> website where people register for API use out-of-band. But since mobile
>>> apps are easily rootable, this is my attempt to close some gaps.
>>> Questions? Comments? All input, good, bad, or neutral are welcome.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DotNetOpenAuth" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/dotnetopenid/-/gvTXeUWDy9wJ.
>> To post to this group, send email to dotnetopenid@googlegroups.com.
>> To unsubscribe from this group, send email to
>> dotnetopenid+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/dotnetopenid?hl=en.
> --
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
> --
> You received this message because you are subscribed to the Google Groups
> "DotNetOpenAuth" group.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
And thank *you* for advocating the best practices that we'd like to see. I
hope we see either a solution to the UX problem of the security route, or a
general acceptance and adoption of it as-is, in the near future for the
good of user security. :)
On Tuesday, July 24, 2012, Brad Laney wrote:
> Thanks. I forwarded your opinions (I share them) to my team, but I lost
> the battle! We are going to include the "application id" (the id in the
> app) for at minimum, logging purposes. But I made it fairly clear to them
> that the application is still to be considered not trusted, and only
> confidential. This also gives us the ability to invalidate all client
> registrations and tokens based on the application id.
> The idea is that if ABC Company uses us and wants to make a non-trusted
> app, we give them an application id and they use that for dynamic
> registration. If for some reason they break our usability rules and we want
> to prevent them from getting keys, we can expire their application ID and
> they can no longer register.
> So it became more of a non-malicious user tracking code, than a secure
> one. I just made it very clear that we cannot rely on it to give us
> security.
> Thanks for all the helpful feedback, it's really refreshing to actually
> get active support on some open source software for once.
> P.S. I tried to advocate for using true OAuth2 Authorization Code Grants
> but I couldn't convince anyone else that it's a good idea to do over the
> usability of an in-app registration. They don't even want third parties to
> have to open a webview :/
> On Tue, Jul 24, 2012 at 11:57 AM, Andrew Arnott <andrewarn...@gmail.com>wrote:
> You should assume that decompiling an obfuscated app is quite doable.
> What with the arms race for apps like iTunes, you know that not even
> Apple, whose major income depends on the DRM it applies to music, can't
> avoid having its encryptions cracked since ultimately the ability to
> decrypt is inside the client just waiting to be discovered.
> What I meant by dynamic registration is that an anonymous client can
> become confidential -- not trusted, simply confidential. This means you
> don't really know what app is on the client, but at least you know on a
> subsequent call that it's the *same* client that had registered
> previously. This is enough security to protect OAuth 2 tokens, but only
> you can decide whether that's enough to protect the user's data and your
> server resources.
> Ultimately, the only way to prevent others from being able to tamper with
> your app or create a look-alike is to not use a client app at all, but
> rather keep your app as a web site, where a client secret can be securely
> stored, and accept that anyone can create local clients that even drive
> that web site. After all, that's what all browsers themselves do.
> It comes down to what you're protecting. Your income perhaps, which can
> come from selling the app itself and selling a subscription to your online
> service, and you're probably protecting some user data. The online service
> and user data are all on the server, so that's something that OAuth 2 can
> protect. Your app can be protected by the mobile app store(s). But other
> folks can create look-alikes, and the only way to prevent that is through
> legal action.
> On Tuesday, July 24, 2012, Brad Laney wrote:
> Yes, that's true. If they manage to decompile an obfuscated mobile app,
> then yes they could find the password.
> What else am I supposed to do? This is the best thing I could come up with.
> Even if I used private certificate that could be taken off the phone as
> well.
> In a previous post I thought this is what you mentioned to do, with
> dynamic registration. I thought what's the point of dynamic registration if
> anyone can do it. So I tried to put in a solution to prevent people from
> being able to do public registrations.
> On Monday, July 23, 2012 2:15:41 PM UTC-5, Brad Laney wrote:
> Brief introduction of what I am trying to accomplish. I am attempting to
> use the Resource Owner Password Credentials Grant. The reasoning being that
> I do not want any limited experience to the end user for our applications.
> They must have a full in-app experience without interruption.
> My concerns:
> Using dynamic registration seems to be worthless. If a public end user can
> register any user any time they want if they get the username and password,
> then the registration stopped nothing. The whole point of client
> registration is so that only that client may have access.
> My solution:
> 1) A resource owner downloads the application
> 2) The resource owner enters their username and password credentials into
> the client form
> 3) The username and password are kept only in memory during
> the following process and is dropped when the registration is complete
> 4) The phone application is compiled with a registration identifier. This
> is used in registration requests as a mechanism to prevent public
> registrations.
> 5) Registration is made against an endpoint over SSL passing the
> registration identifier, resource owner username and password.
> 6) The client receives a client_id and client_secret. The client_id is the
> username, and the client_secret is a cryptography random key locked to the
> username (client_id).
> 6a) If a client_secret exists for this user, it will be returned, no new
> key will be generated.
> 7) Registration is complete, from here on out it is standard resource
> owner password credentials
> Notes
> The client_secret will be stored in a cryptography keystore local on the
> phone. New devices added for that user will have the same.
> The whole point of this is to prevent public registrations, such as if
> someone makes a wanna-be phone app that looks like ours.
> Is it even important to prevent public registrations? I am just very weary
> about supporting dynamic registration, I would pr
-- --
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
