What do you think of this authentication solution for phones?

[Brad Laney]

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.

[Andrew Arnott]

Hi Brad,

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.  

Is that not so?

--
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 dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@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

[Brad Laney]

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.

[Andrew Arnott]

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.

--

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 dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

[Brad Laney]

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 :/

[Andrew Arnott]

You're welcome.  I'm glad I could help.  

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