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
