Am 18.09.2010 01:28, schrieb Kris Selden:
Secrets on native apps are good! The key is (no pun intended) that the secret
not ship with the app. Each client should register for its own client_id and
secret when it is installed on the client machine.
Maybe I'm missing something but...
If it has no credentials, why does sending it credentials after it has been
installed, prove the client app is trusted? Isn't an installed app without
credentials, an untrusted app? How do you know when you register the client
that it is the app you think it is?
What can the client you want to register do that a client you don't want to
register can't after install?
How would say an iPhone client that I download register? Push notifications?
What if the end user hasn't enabled them? (I know a lot of people who turn them
off) Also, if they've been hacked on a jailbroken phone
(http://www.pushfix.info) are they really proving that the client is the client
you think it is?
"The specification is very clear (as the article quotes) – don’t use client secrets
in installed applications! The reason why the specification doesn’t say much more is
because there is no solution. It does not exist for a distributed application unless you
issue a different secret to each installation."
http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/
Once the secret is installed isn't it still vulnerable after installation? Or
is it because you can revoke the one abused secret (after detecting that it has
been abused) without invalidating all the installed clients.
It seems like what would be ideal is if these mobile app marketplaces could
install a unique client secret when an app is purchased. Otherwise I would
think an untrusted app could just mimic a trusted app during registration.
that's a very interesting idea but it requires a strong trust
relationship between app marketplace and authorization server.
In my opinion, client secrets dynamically issued by the OAuth
authorization server might at most be a solution against session
fixation attacks (cf.
http://www.ietf.org/mail-archive/web/oauth/current/msg04358.html).
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
