Re: [OAUTH-WG] why are we signing?

[Dick Hardt <[e-mail]>]

On 2009-11-09, at 6:47 PM, John Panzer wrote:

> On Mon, Nov 9, 2009 at 6:09 PM, Dick Hardt  
> <[e-mail]> wrote:
>>
>> On 2009-11-09, at 4:34 PM, John Panzer wrote:
>>
>>> Counter-argument:  The login pages are protected with https, so
>>> their password is protected.
>>
>> One might then ask why HTTPS is not used for all the other activity  
>> if
>> it is sensitive. HTTPS is available. Crypto gets cheaper and cheaper
>> with Moore's law.
>
> It would be interesting to see the price differential (for peak
> traffic/worst case scenario you need to provision for).

That would be interesting.

>
> Imagine that the resource is, say, a 10MB image.

Setting up the connection is pretty expensive compared to moving data.

>
>>
>>
>>>  Their session cookies are sent in clear text but are themselves
>>> encrypted and are refreshed every (say) 10 minutes to minimize
>>> exposure from leakage.
>>
>> A lot of damage could be done in those ten minutes.
>
> But much less than can be done if passwords can be collected and used
> later when the user is asleep, to access arbitrary services (and
> probably unrelated services because everyone is using the same
> email-based username and low-security password for everything).

Clearly. Point being that lots of damage can happen in ten minutes.  
Take Twitter for an example, I can send LOTS of spam to all your  
followers as direct messages and follow a bunch of people you don't  
want to follow. I have gotten malware spam from other people's Twitter  
accounts.

>
>>
>>> The user's data certainly is sent in clear text form and an attacker
>>> can both read it and impersonate the user to send data if they grab
>>> the cookies, at least for 10 minutes.  So I got nothin' there.
>>>
>>> (Would bearer token plus a way to securely rotate the token every N
>>> minutes make the OAuth session at least as secure as the above
>>> scenario?)
>>
>> I think so. :-)
>
> Don't we want that anyway?

Yes. Refreshing the Access Token is a recommendation in WRAP.

-- Dick