Hi Thomas,
Am 02.06.2011 21:17, schrieb Thomas Hardjono:
Hi Torsten, folks,
I reviewed the text of Section 4.1 of draft-lodderstedt-oauth-security, and
also the text of Section 9 of oath-draft16.
I think there seems to be a disconnect (may be its just me).
(a) Oauth2.0 today is designed for low-assurance environments. So I think the
WG is wasting a lot of time in trying to address whether the Client can keep
secrets. The WG should just assume that the problem of keeping secrets is out
of scope for Oauth. Unless we are trying to address high-assurance environments
(and start talking about smartcards, HSMs, TPMs, trusted execution, trusted
boot, etc), I think the WG should just move on.
ps. Section 4.1 is OK, but this WG will not be able to solve many of the
problems listed in Section 4.1
(b) The current text of Section 9 says:
]]]] Native applications SHOULD use the authorization code
]]]] grant type flow without client password credentials (due to their
]]]] inability to keep the credentials confidential) to obtain
]]]] short-lived access tokens, and use refresh tokens to maintain access.
When it comes to "keeping secrets" I don't know why we are assuming that a
native application (software running in user-space managed by an OS) is any worse than a
browser (user-agent). Did I misunderstood the definition of a native application?
I would assume "a browser" refers to apps running within the browser.
http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10 calls them
user-agent-based apps. For both user-agent-based and native apps, the
text states the assumption that "The OAuth protocol data and credentials
are accessible to the end-user.". So both are equivalent with respect to
the topic discused in this thread. For native apps, another important
issue is the way their client secret (today) is typically assigned and
distributed (backed into the binary). So the same secret is accessible
in all installations. This is considered bad practice by many people.
Web applications are quite different since the OAuth credentials are
kept in a server under control of the service provider and not
accessible to the end-user.
regards,
Torsten.
Thanks.
/thomas/
_________________________________
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Thursday, June 02, 2011 5:00 AM
To: Skylar Woodward
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Text for Native Applications
Dave, Skylar,
the assumption of the OAuth 2.0 security threat model
(http://tools.ietf.org/html/draft-lodderstedt-oauth-security-
01#section-4.1)
is that client secrets, which are distributed with applications, cannot
reliably kept confidential. Therefore the advice is given to use other
means to validate the client identity (e.g. user consent, platform
security measures).
I would highly appreciate if you would review this document and give us
feedback.
thanks in advance,
Torsten.
Am 01.06.2011 22:07, schrieb Skylar Woodward:
On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote:
for mounting the attack. I firmly believe that secrets can be
sufficiently obfuscated in code delivered in binary format without
the benefit of a symbol table, so as to be sufficiently resistant to
discovery via disassembly by attackers you'd expect to encounter in
a
typical commercial environment. I'm not talking about printable
I have empirical evidence to support this. At Yahoo! we devised one
of the most complex systems I've ever seen in a publicly distributed
program (Messenger). It was disassembled in 3 days. Scott Renfro (now
over with David at Facebook) and likely Bill Mills can also vouch for
the difficulty of this having also studied the case well.
Moreover if a hardware-enforced system like that of Playstation 3 can
be broken, then so can most systems. The PS3 protection mechanisms
are/were very sophisticated.
Even if a system is not yet cracked or is very hard, you have to
assume it can be cracked. History has shown this to be true nearly
without exception - at least to the point it is not worth considering
for the OAuth use cases.
skylar
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
