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 threat document.
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, why would 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
