Replying everyone all at once...
On 1/13/10 10:30 PM, "John Panzer" <[email protected]> wrote: > > On Wed, Jan 13, 2010 at 10:05 PM, Eran Hammer-Lahav <[email protected]> > wrote: >> In a recent thread [1] on this list we reach (very small) consensus that the >> OAuth 1.0 protocol should mandate HTTPS for the PLAINTEXT method. The >> community edition only recommends it. > > Actually, HTTPS or equivalent channel security was the consensus. It gets exhausting typing that every time. I have to assume people are following the conversation a bit... :-) >> >> QUESTIONS: Are there any valid (such that will pass IETF security review >> scrutiny) reasons for allowing unsigned requests to be sent in the clear >> over an insecure channel? Are there use cases for this (regardless of their >> security properties)? > > There was also a discussion (initiated by Brian Eaton) regarding the > combination of short lived token plus refresh, which should be dug up. This is part of my question - is a fully exposed bearer token with a time limit of an hour (which is what I have heard most of those advocating this approach suggest) provide adequate security in line with IETF security standards. I have a strong feeling it does not... On 1/14/10 3:35 AM, "John Kemp" <[email protected]> wrote: > I am still wavering on this. > > I think that using a bearer token with short lifetime and one-time use > semantics (for example) is probably sufficient security for many use-cases. > And using TLS/SSL (or even just signing and verifying a signed request) in all > cases may provide too much performance overhead for some of those cases. How short lived does it need to be to be sufficient? The attack vector is trivial with the amount of open access points people use in public places. > In other words, I think that it's not only channel security we need to > consider, but a combination of other measures that would, in some cases, > obviate the need for TLS. Are there other 'combination of other measures' anyone has to offer than making the bearer token short lived? On 1/14/10 4:10 AM, "Blaine Cook" <[email protected]> wrote: > OAuth WRAP is very similar to cookies as deployed by major vendors. Which has been the argument made by some of the WRAP authors. I don't buy it. Using this argument keeps web security broken and based on the broken system we have today. We need to start fixing it somewhere and this is a goof place. > Google has just switched to HTTPS-by-default for all GMail > sessions[1], and my understanding (per [2]) is that access to > authenticated sessions (i.e., full GMail or Google Docs access versus > just displaying "[email protected]" on the page) is always negotiated with > a secure cookie. Thus, Google has made decisions internally to secure > the equivalent of both the Refresh and the Bearer token, short-lived > assurances aside. > > We're also entering an age where we have enough computing power to > *factor* RSA-1024 in non-infinite-time; handheld devices that are > realistically expected to use these protocols have sufficient > computing power and battery life to encrypt HTTP requests and decrypt > the responses (my phone already does this for all Twitter and email > requests; yours probably does, too). > > As such, I can't see how *not* requiring SSL for unsigned requests > could pass muster at an IETF security review. I completely agree. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
