Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

[George Fletcher <[e-mail]>]

The problem is that even if the Authorization Server only gives out 
credentials to "trusted clients", those clients can be "hacked" and the 
credentials compromised allowing for impersonation of the "trusted 
client". Obviously, protecting the credentials is easier if the client 
is a web server with the appropriate security measures in place.

However, that isn't the only use case that needs to be solved. Rich 
desktop applications and mobile applications also need access to the 
user's protected resources. The issue here is that clients (in the vast 
majority of cases) can't be trusted.

This means that all rich desktop/mobile app models currently in the 
field are flawed (if we are trying to protect the user from a malicious 
client). OAuth is specifically NOT trying to solve the "client 
trustworthiness" problem. Personally, I don't see how to solve this 
problem without "trusted hardware" in the client and that isn't yet 
widely deployed.

However, as others have pointed out, OAuth doesn't make the existing 
situation worse (i.e. users are just as likely without OAuth to download 
malicious code to their computers/devices and be phished). However, with 
more "good" applications moving to OAuth, the situation generally 
improves for the user, because their credentials are stored in fewer 
places. It might even push the "bad guys" to having to implement 
malicious apps as other methods of getting the user's credentials are 
significantly reduced.

 From a threat model perspective, while OAuth doesn't solve this 
specific threat, the use of OAuth overall improves the security of the user.

My 2 cents:)

On 1/5/12 11:48 AM, Michael Thomas wrote:
>
> Second: I don't think that the suggestion should be that the markets do
> this vetting -- they won't because they aren't fate shared. The auth 
> server,
> on the other hand, has the ability to not enroll clients. That at least
> is plausible rather than the completely implausible suggestion that
> billions of users educate themselves on millions of apps.
>
> Mike
>
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
>>
> -- 
>> *From:* Mark Mcgloin <[e-mail]>
>> *To:* William Mills <[e-mail]>
>> *Cc:* Barry Leiba <[e-mail]>; Michael Thomas 
>> <[e-mail]>; oauth WG <[e-mail]>; [e-mail]; 
>> Torsten Lodderstedt <[e-mail]>
>> *Sent:* Thursday, January 5, 2012 6:03 AM
>> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, 
>> ends 9 Dec 2011
>>
>> Why do you think this William? Apple does it? Google android market 
>> had to
>> pull 30 apps recently because they contained malware. There are 
>> automated
>> tools that will do some sanity checks on apps and it is only advice, 
>> i.e.
>> 'could'
>>
>> Mark
>>
>> > William Mills <[e-mail] <mailto:[e-mail]>>
>> >
>> >  "  o  Client applications could be validated prior publication in a
>> >      application market."
>> >
>> > Should just be struck.  Michael is correct that it's fluff, and
>> > unenforceable.  There are too many app marketplaces, opensource
>> > projects, etc. to make this a useful suggestion.
>> >
>> > From: Michael Thomas <[e-mail] <mailto:[e-mail]>>
>> > To: Torsten Lodderstedt <[e-mail] 
>> <mailto:[e-mail]>>
>> > Cc: Barry Leiba <[e-mail] 
>> <mailto:[e-mail]>>; oauth WG <[e-mail] 
>> <mailto:[e-mail]>>
>> > Sent: Wednesday, January 4, 2012 3:40 PM
>> > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01,
>> > ends 9 Dec 2011
>> >
>> > On 01/04/2012 02:14 PM, Torsten Lodderstedt wrote:
>> > > Hi Michael,
>> > >
>> > > Am 04.01.2012 22:06, schrieb Michael Thomas:
>> > >> I think the "perhaps unwisely" goes to the heart of my 
>> objection. You
>> > >> might as well be talking about "perhaps unwisely" driving a car,
>> > >> or "perhaps unwisely" eating food: the reality is that people 
>> download
>> > >> apps by the *billions*.  When I was initially blown off, many of 
>> the
>> > >> participants including document editors implied that only idiots 
>> get
>> > >> apps for their phones. That is *completely* unhelpful as the 
>> reality
>> > >> is that OAUTH's use is hugely if not primarily deployed in that 
>> sort
>> of
>> > >> environment.
>> > >
>> > > I fully agree with you. That's why the core spec and the threat
>> > document both consider native apps.
>> > >
>> > >>
>> > >> This is a threat that cuts to the very heart of what OAUTH is, and
>> purports
>> > >> to defend against: keeping user credentials out of the hands of an
>> > >> untrusted third party. If there really aren't any good ways to
>> > mitigate this
>> > >> in an app environment, why is OAUTH being deployed so aggressively
>> there?
>> > >> Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH
>> > >> IN NATIVE APPS CONSIDERED HARMFUL"?
>> > >
>> > > You lost me. Is the situation getting any worse with OAuth? I
>> > don't think so. I think the situation is getting better, probably
>> > not as you might expect.
>> >
>> > My concern is that putting on a veneer of "security" will lull people
>> into
>> > thinking "Oh, it's safe to enter my credentials here because this is
>> really
>> > twitterbook, not evilapp!". When I had to ask them directly to put 
>> their
>> > twitterbook credentials into my app, there at least wasn't any 
>> confusion
>> > that I had access to them.
>> >
>> > Realistically, what you've done is protected the credentials from the
>> good
>> > guys and not changed much for a motivated bad guy. Is that an
>> improvement?
>> > I'll buy that it's generally bad practice for good guys with most 
>> likely
>> bad
>> > security chops to  be storing credentials, but I'm guessing that the
>> original
>> > OAUTH motivation was more toward thwarting bad guys.
>> >
>> > >
>> > > The key question is: Why do we aim on "keeping user credentials
>> > out of the hands of an untrusted third party"?
>> > >
>> > > 1) To prevent phishing or 2) to prevent leakage of end-user
>> > credentials due to inappropriate handling or weak defence on the 3rd
>> party?
>> > >
>> > > wrt 1) I don't think so. I don't see how an authorization server
>> > shall validate the authenticity and trustworthiness of a client-side
>> > application. We already state this in section 4.4.1.4. of the
>> threatdocument.
>> >
>> > The draft says:
>> >
>> >  o  Client applications could be validated prior publication in a
>> >      application market.
>> >
>> > I asked -- and didn't get a response -- about how exactly that might
>> > be done. I suspect
>> > that in practice for the twitterbook universe that there is no way
>> > that scales. So the
>> > reality here seems to be there isn't an answer for the Internet at
>> > large, and the threats
>> > document should just say that mitigation MAY be possible in very
>> > narrow use cases where
>> > code reviews, and other heavy handed analysis can be performed, but
>> > for the general case
>> > there is no mitigation.
>> >
>> > As far as 4.4.1.4 goes, I'd say that the counter measures really
>> > don't help except
>> > maybe for auditing. If that's what they're really about, the draft
>> > should make that
>> > explicit.
>> >
>> > Also on the subject of 4.4.1.4, this bullet:
>> >
>> >
>> > o  If the authorization server automatically authenticates the end-
>> >      user, it may nevertheless require some user input in order to
>> >      prevent screen scraping.  Examples are CAPTCHAs or user-specific
>> >      secret like PIN codes.
>> >
>> >
>> > I'm very skeptical because a native environment is a social
>> > engineering nirvana.
>> > The CAPTCHA could easily be shown to the user and they'd blissfully
>> > solve it just
>> > like they do any other one.
>> >
>> >
>> >
>> >
>> > >
>> > > -----------------------
>> > > It is not the task of the authorization server to protect
>> > >    the end-user's device from malicious software.  This is the
>> > >    responsibility of the platform running on the particular device
>> > >    probably in cooperation with other components of the respective
>> > >    ecosystem (e.g. an application management infrastructure).  
>> The sole
>> > >    responsibility of the authorization server is to control 
>> access to
>> > >    the end-user's resources living in resource servers and to 
>> prevent
>> > >    unauthorized access to them.
>> > > -----------------------
>> >
>> > I assume that it's in the authorization server's _interest_ to not
>> divulge
>> > user credentials to potentially evil third parties. If it's not, 
>> whywould
>> you
>> > go to the trouble of implementing OAUTH at all?
>> >
>> > This is what's so troubling to me. The point is to keep user 
>> credentials
>> away
>> > from bad guys, but when shown how OAUTH in widely deployed scenarios
>> fails
>> > to do that, the response I get from the working group is "Not Our
>> Problem".
>> > Well it *is* your problem insofar as you are not advising the
>> twitterbooks to
>> > disallow native apps as clients, for example.
>> >
>> > >
>> > > wrt 2) Yes, I think that's the reason. And OAuth is a appropriate
>> > protocol to achieve this goal, even for mobile apps. Why?
>> > >
>> > > A typical mobile application consists of the app itself on the
>> > device and a corresponding backend service storing user data and
>> > implementing business and integration logic. Let's assume this
>> > application features address book import from other service
>> > providers. W/o OAuth, the app would gather the end-user's credential
>> > for a certain address book service and pass it to its backend
>> > service. This service in turn uses this credentials to access the
>> > service provider's API. So in such a scenario the following parties
>> > get in touch with the user credentials:
>> > > - the app
>> > > - the app's backend service
>> > > - the address book resource server
>> >
>> > With native mobile apps, the client (= app & app backend) isn't it 
>> plenty
>> > enough to be seriously scary if they can screen scrape the credentials
>> > with impunity? What problem was solved again?
>> >
>> > >
>> > > What threats do you see here? And which is most likely to occur?
>> > My favorite is an attack against the log files or the database of
>> > the backend service in order to obtain the end-users passwords for
>> > the resource server. Why? Because the cost/benefit ratio for an
>> > attacker is much better then attacking any app installation on a
>> > device and the protective measure on the resource server might be
>> > more appropriate then on the client side (backend service).
>> >
>> > Botnets prove that either is a successful business model. This isn't a
>> zero
>> > sum game, after all.
>> >
>> > > OAuth mitigates this kind of attack by reducing the number of
>> > parties handling user credentials to the authorization server and
>> > the user agent. So even if the app itself would be the user agent
>> > (which is not recommended),
>> >
>> > Not recommended? It's messed up even thinking of it that way. The
>> > app is potentially
>> > *evil*. It really doesn't care what the IETF RECOMMENDS. If it's
>> > useful for it to be the
>> > UA, it's going to do just exactly that.
>> >
>> > > it would directly interact with the authorization server and the
>> > app's backend service would use tokens instead of end-user 
>> credentials.
>> >
>> > The problem here is the capture of end user credentials. I believe 
>> that
>> OAUTH
>> > defends pretty well in the trusted desktop browser scenario it set
>> > out to solve
>> > for. I do not believe that it does that in the new reality of native
>> > apps, and embedded
>> > webviews.
>> >
>> > | Moreover, the recommended way is to let the app delegate the flow
>> > to a trusted system
>> > | component on the user's device, such as the system browser or an
>> > account manager. In that
>> > | case, the 3rd party is not getting in touch with the user
>> > credentials at all.
>> >
>> > Again, the Bad Guys are specifically and completely uninterested in
>> > being good and
>> > sending it to a trusted component. They will disregard this RECOMMEND
>> faster
>> > than you can type it.
>> > >
>> > > I think the key question is whether anyone expects OAuth to solve
>> > the phishing problem. I don't think this is its main purpose, but it
>> > could facilitate to overcome the habit to enter user credentials
>> > everywhere. And this in turn may contribute to the fight against
>> phishing.
>> >
>> > There's much more to this than just phishing.
>> >
>> > Mike
>> > _______________________________________________
>> > OAuth mailing list
>> > [e-mail] <mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > [e-mail] <mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>