Re: [OAUTH-WG] problem statement
Justin Richer <jricher@mitre.org> Tue, 06 September 2011 18:48 UTC
Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CA721F8D59 for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 11:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level:
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsxWoa01BiZG for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 11:48:11 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EC27C21F8D29 for <oauth@ietf.org>; Tue, 6 Sep 2011 11:48:10 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D2F1C21B16B0; Tue, 6 Sep 2011 14:49:57 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CC30821B16A4; Tue, 6 Sep 2011 14:49:57 -0400 (EDT)
Received: from [129.83.50.1] (129.83.31.55) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server id 14.1.270.1; Tue, 6 Sep 2011 14:49:57 -0400
From: Justin Richer <jricher@mitre.org>
To: Michael Thomas <mike@mtcc.com>
In-Reply-To: <4E6667D1.3080404@mtcc.com>
References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <CD0B1909-8298-4CC3-B273-7B26E71EAB31@hueniverse.com> <4E666512.7010701@mtcc.com> <F4839FCD-CA73-4450-AD12-E07D46BB7746@hueniverse.com> <4E6667D1.3080404@mtcc.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 06 Sep 2011 14:48:55 -0400
Message-ID: <1315334935.3136.29.camel@ground>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] problem statement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2011 18:48:12 -0000
Mike, The basic argument here is that if the app wants to do bad things, and you go through the process of authorizing it, it's going to be able to do bad things. Not just to your stolen credentials, either, since it's now got an access token too. OAuth's trust model does work with installed applications -- however, there are several caveats. This is one of them, as is the fact that they can't be shipped with secured secrets (ie, client secrets). And it's exactly this acquiescence to their limitations that opens the way for things like the username/password flow in OAuth2. In this flow, the app just asks for the user's username and password directly and exchanges them for an access token. There is still a distinction from logging in directly with the user's credentials to the API endpoint though. First, the user's credentials don't get tossed out onto the wire with every request. This lessens the susceptibility to theft in transmission. Second, the app doesn't *have* to store the credentials. After the first step goes through and the app gets a token, it can toss them. That way nobody can steal the credentials out of an on-disk store after the fact. If it wants to hang on to them, then yeah, you're absolutely right -- it has your credentials and you're hosed. But nothing in the OAuth protocol is going to force a misbehaving application to not do that. Just like nothing in the OAuth protocol is going to stop phishing attempts to look like the Twitter login screen. A solution to not letting an app steal your credentials is to not use credentials in the first place and to use things like a rotating token or a client-side certificate instead of a username/password to authenticate the user during the authoirzation flow. Since OAuth doesn't care how the user authenticates in the verification code flow, you don't even have to change your client code. We actually had this happen locally when developers moved from one environment that used username/password and into another that used OpenID. The OAuth code didn't change at all between them. But ultimately, a bad app is going to be a bad app, and you need to be careful what software you run and where you type your password. I think it's a mistake of this group to flippantly ignore the threat, but at the same token this reality does not make the OAuth protocol or its underlying model useless. -- Justin On Tue, 2011-09-06 at 14:34 -0400, Michael Thomas wrote: > Eran Hammer-Lahav wrote: > > Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. > > > > If there was a solution to this we would not need an antivirus. > > How exactly does an end user know what is "crap" or not? Or are you just dismissive of apps in > general? I don't think that apple and google are going to close up shop because it breaks oauth's > trust model. > > Mike > > > > > EHL > > > > On Sep 6, 2011, at 11:23, "Michael Thomas" <mike@mtcc.com> wrote: > > > >> Eran Hammer-Lahav wrote: > >>> I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. > >> How, exactly, is the user supposed to protect themselves against rogue apps? > >> It sounds like the solution is to tell them to never use oauth in an app at all. > >> > >> Is oauth only intended to be used on standalone trustable web browsers? I don't recall > >> seeing that anywhere. > >> > >> Mike > >> > >>> EHL > >>> > >>> On Sep 6, 2011, at 11:10, "Igor Faynberg" <igor.faynberg@alcatel-lucent.com> wrote: > >>> > >>>> Mike, > >>>> > >>>> You've got the problem statement right: allowing the user to authorize > >>>> resource access to another party without divulging user's credentials is > >>>> the objective of OAuth. You are also right in that the attack you have > >>>> described defies the whole purpose of OAuth. I do not think though that > >>>> it is related to OAuth per se. > >>>> > >>>> To this end, the security work led by Torsten has thoroughly analyzed > >>>> the protocol and specified protection against multiple protocol > >>>> attacks. From what you described, it appears to me that the attack you > >>>> mention is not related to the protocol but rather to the user's > >>>> environment. There is no possible protection from key loggers that a > >>>> protocol can implement. I could be mistaken; in any case, it looks like > >>>> the problem rests with the implementation of WebView. > >>>> > >>>> If I am wrong, I would appreciate a detailed description of what happened. > >>>> > >>>> Igor > >>>> > >>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: > >>>>> Hi all, > >>>>> > >>>>> Barry suggested that I might subscribe and explain what I sent him. > >>>>> > >>>>> My basic problem is that in neither the protocol nor the threats drafts, > >>>>> I can't seem to find what problem is actually trying to be solved with > >>>>> oauth, and what assumptions you're making about various elements. > >>>>> > >>>>> Here's what I did. I've written an app, and I wanted re-integrate the > >>>>> ability to send tweets after they deprecated Basic. So the app has a > >>>>> webView (android, iphone...) which it obviously completely controls. > >>>>> With oauth, the webview UA will ultimately redirect off to Twitter's > >>>>> site to collect the user's credentials and grant my app's backend an > >>>>> access token (sorry if I get terminology screwed up, i'm just coming > >>>>> up to speed). > >>>>> > >>>>> What occurs to me is that webview affords exactly zero protection from > >>>>> my client (ie, the app) from getting the user's twitter credentials. All > >>>>> I have to do is set up a keypress handler on that webview and in a few > >>>>> minutes of hacking I have a key logger. etc. > >>>>> > >>>>> So what I can't tell is whether this is a "problem" or not, because I > >>>>> don't know what problem you're trying to solve. If the object of oauth > >>>>> isn't to keep user/server credentials out of the hands of a third party, > >>>>> then what is it trying to solve? Is there an expectation that the > >>>>> UA is trusted by the user/server? What happens when that's not the case? > >>>>> > >>>>> Regardless of whether I'm misunderstanding, it would sure be nice to have > >>>>> both the problem and your assumptions laid out, hopefully with some > >>>>> prominence > >>>>> so you don't get these sort of dumb questions. > >>>>> > >>>>> Mike > >>>>> _______________________________________________ > >>>>> 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] problem statement Paul Madsen
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement Michael Thomas
- [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement William Mills
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement William Mills
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Justin Richer
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Jill Burrows
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Justin Richer
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement William Mills
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement William Mills
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Manger, James H
- Re: [OAUTH-WG] problem statement Justin Richer
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement David Waite
- Re: [OAUTH-WG] problem statement Phil Hunt
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Ben Niven-Jenkins
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement David Recordon
- Re: [OAUTH-WG] problem statement Thomas Hardjono
- Re: [OAUTH-WG] problem statement Phil Hunt