Ethan, On Mar 7, 2010, at 3:13 PM, Ethan Jewett wrote:
> John, > > Yes, I overstepped in the first section. I'll retract all the stuff > about bearer-tokens over an insecure channel not having a use-case. > Clearly they're used all over the place. Whether or not this is a good > idea is another question entirely and you've outlined a good way to > approach it. > > My point is only that bearer-tokens over an insecure channel seem to > be always *less* secure or *as* secure (but never *more* secure) than > using a signature approach over an insecure channel. Agreed, there is a spectrum of security requirements and associated methods of meeting those requirements. Bearer tokens are a relatively weak source of authentication, whereas cryptographic signatures can better provide that property. > As such, I'm > uncomfortable taking away an existing, widely implemented, and usually > more secure approach for authentication over an insecure channel > (OAuth 1.0a signing) and replacing it with a less secure approach > (bearer tokens w/o SSL/TLS). I would certainly not suggest that we replace a relatively secure authentication mechanism (signatures using an appropriately-handled secret key) with a relatively insecure authentication mechanism (bearer tokens in the clear). SSL/TLS (or equivalent) provides another property of security (confidentiality). Any of these mechanisms might find an appropriate place in real-world implementations. Cheers, - johnk > > Ethan > > On Sun, Mar 7, 2010 at 1:40 PM, John Kemp <[email protected]> wrote: >> On Mar 7, 2010, at 12:24 PM, Ethan Jewett wrote: >> >> [...] >> >>> In my opinion, #5 makes bearer-tokens without SSL/TLS unusable in >>> nearly all use cases. >> >> Just to point out that there are many use-cases which are today solved >> *only* with "bearer tokens" - namely any authentication method which uses >> regular Web cookies. >> >> Cookies are often sent over an insecure channel. They are usually not >> signed. And any request which comes with a valid "session cookie" is assumed >> to be from a legitimate requester, even though with cross-site attacks >> through browsers, this is often a devastatingly wrong assumption (hence the >> need for a browser same-origin policy). >> >> But the world has not collapsed. >> >>> Any use case where spam is a threat, for >>> example, is not an acceptable use case because of this attack because >>> any MITM can send an arbitrary number of spam messages that the >>> provider application will show as coming directly from the user. If >>> you think Twitter direct-message spam is bad now... >> >> You are talking about the /impact/ of an attack, and the impact of an attack >> on a system secured only with bearer tokens is often high. There is usually >> at least one other factor in security threat analysis, however - the /risk/ >> of a threat. >> >> The risk of an attack on bearer tokens seems to be empirically low, despite >> the relative ease of such an attack. >> >> The risk can also be mitigated by making bearer tokens expire quickly, or >> have one-time use semantics. >> >> In short, bearer tokens work for quite a large set of use-cases. >> >>> >>> Because of this and other possible attacks (successfully impersonating >>> a provider gets you the bearer-token, for example), I think that >>> bearer-tokens without SSL/TLS are not worth considering further for >>> the vast majority of use cases. >> >> I disagree, but I'm not sure it matters anyway for the purposes of deciding >> what features OAuth should support. >> >> OAuth will support bearer (ie. unsigned) tokens sent over SSL. So it will >> support bearer tokens. It's just a question of whether the spec. should >> allow implementations to send bearer tokens over any other channel than an >> SSL/TLS channel. >> >> If someone wishes to do the risk analysis and decides that a particular >> security feature is sufficient for what they want to do, why shouldn't they >> be allowed to do it? Someone who gets it wrong, shoots him- or her-self (and >> no-one else, as the whole community, or that company's partners don't have >> to play along) in the foot, right? >> >> Make bearer+SSL/TLS mandatory to implement, but don't rule out bearer tokens >> being sent over insecure channels, and we should all be able to implement >> what we need to implement in peace. >> >> Cheers, >> >> - johnk >> >> >> >> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
