Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Martin Atkins]

Allen Tom wrote:
> 
> For the time being, we prefer to require CKs for client applications 
> (even if they can't be verified) mostly to make it easy for us to pull 
> the plug on specific applications if they are discovered to be severely 
> buggy or dangerous. We'd also like to require pre-registration of CKs so 
> that we know who to contact about a particular app if we have any questions.
> 

If I make a dangerous app using the consumer key from a popular 
application, would you black list that key and inconvenience all of its 
users?

(I doubt it.)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Breno de Medeiros]

On Tue, Dec 2, 2008 at 4:58 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
> It's definitely bad hygiene for developers to leak their secrets to the
> browser, or to reuse their website's CK for a downloadable client
> application, and we're doing all that we can to encourage good hygiene.
>
> For the time being, we prefer to require CKs for client applications (even
> if they can't be verified) mostly to make it easy for us to pull the plug on
> specific applications if they are discovered to be severely buggy or
> dangerous. We'd also like to require pre-registration of CKs so that we know
> who to contact about a particular app if we have any questions.

Sounds reasonable.

>
> Allen
>
> Breno de Medeiros wrote:
>
> Interesting point, and probably worth adding to a security portion of the
> spec.
>
> I would say though, that is bad security hygiene to share the same
> consumer key between your web and desktop apps. Since we can't vouch
> for consumer keys stored in desktop apps anyway, I would volunteer
> that the most sensible thing is to have empty consumer keys in that
> case (and warn users that we can't vouch for the origin of the
> request).
>
> On Tue, Dec 2, 2008 at 4:37 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
>
>
> Dirk Balfanz wrote:
>
> On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
>
>
>
> In Section 10, and perhaps also in Section 12, the spec should mention
> that because the hybrid protocol does not have a request token secret, and
> because the user is never required to manually type in the request token
> (unlike in OAuth), the hybrid Request Token probably should be longer and
> harder to guess than the standard OAuth Request Token. At least for our
> implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret.
>
>
> But you need to have the consumer secret to exchange it, no? What if it were
> just a incrementing integer? What would the attack be?
>
> Yes, the attacker would still need the Consumer Secret, however in vanilla
> OAuth, the attacker would need the Consumer Key, Consumer Secret, Request
> Token, and Request Token Secret. Because there's one less secret, the Access
> Token could be more vulnerable to hijacking from brute force attacks where
> RTs are just randomly scanned.
>
> In our case, Yahoo issues relatively short Request Tokens from a limited
> character set to make them easy to type. We compensate for the short RTs by
> pairing them with long RTSecrets. If we were to implement the hybrid
> protocol, our hybrid RTs would be much longer than the regular OAuth RTs.
>
> We also believe that developers may inadvertently leak their Consumer
> Secrets. We're seeing lots of questions from developers who are trying to
> use OAuth from within Javascript and Flash, which implies that they're going
> to be leaking the secret to the browser. Developers may also reuse their
> website's Consumer Key into a downloadable client application.
>
> Allen
>
>
>
>
>
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

It's definitely bad hygiene for developers to leak their secrets to the 
browser, or to reuse their website's CK for a downloadable client 
application, and we're doing all that we can to encourage good hygiene.


For the time being, we prefer to require CKs for client applications 
(even if they can't be verified) mostly to make it easy for us to pull 
the plug on specific applications if they are discovered to be severely 
buggy or dangerous. We'd also like to require pre-registration of CKs so 
that we know who to contact about a particular app if we have any questions.


Allen

Breno de Medeiros wrote:

Interesting point, and probably worth adding to a security portion of the spec.

I would say though, that is bad security hygiene to share the same
consumer key between your web and desktop apps. Since we can't vouch
for consumer keys stored in desktop apps anyway, I would volunteer
that the most sensible thing is to have empty consumer keys in that
case (and warn users that we can't vouch for the origin of the
request).

On Tue, Dec 2, 2008 at 4:37 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
  

Dirk Balfanz wrote:

On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <[EMAIL PROTECTED]> wrote:



In Section 10, and perhaps also in Section 12, the spec should mention
that because the hybrid protocol does not have a request token secret, and
because the user is never required to manually type in the request token
(unlike in OAuth), the hybrid Request Token probably should be longer and
harder to guess than the standard OAuth Request Token. At least for our
implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret.
  

But you need to have the consumer secret to exchange it, no? What if it were
just a incrementing integer? What would the attack be?

Yes, the attacker would still need the Consumer Secret, however in vanilla
OAuth, the attacker would need the Consumer Key, Consumer Secret, Request
Token, and Request Token Secret. Because there's one less secret, the Access
Token could be more vulnerable to hijacking from brute force attacks where
RTs are just randomly scanned.

In our case, Yahoo issues relatively short Request Tokens from a limited
character set to make them easy to type. We compensate for the short RTs by
pairing them with long RTSecrets. If we were to implement the hybrid
protocol, our hybrid RTs would be much longer than the regular OAuth RTs.

We also believe that developers may inadvertently leak their Consumer
Secrets. We're seeing lots of questions from developers who are trying to
use OAuth from within Javascript and Flash, which implies that they're going
to be leaking the secret to the browser. Developers may also reuse their
website's Consumer Key into a downloadable client application.

Allen








  


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Breno de Medeiros]

Interesting point, and probably worth adding to a security portion of the spec.

I would say though, that is bad security hygiene to share the same
consumer key between your web and desktop apps. Since we can't vouch
for consumer keys stored in desktop apps anyway, I would volunteer
that the most sensible thing is to have empty consumer keys in that
case (and warn users that we can't vouch for the origin of the
request).

On Tue, Dec 2, 2008 at 4:37 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
> Dirk Balfanz wrote:
>
> On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
>
>>
>> In Section 10, and perhaps also in Section 12, the spec should mention
>> that because the hybrid protocol does not have a request token secret, and
>> because the user is never required to manually type in the request token
>> (unlike in OAuth), the hybrid Request Token probably should be longer and
>> harder to guess than the standard OAuth Request Token. At least for our
>> implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret.
>
> But you need to have the consumer secret to exchange it, no? What if it were
> just a incrementing integer? What would the attack be?
>
> Yes, the attacker would still need the Consumer Secret, however in vanilla
> OAuth, the attacker would need the Consumer Key, Consumer Secret, Request
> Token, and Request Token Secret. Because there's one less secret, the Access
> Token could be more vulnerable to hijacking from brute force attacks where
> RTs are just randomly scanned.
>
> In our case, Yahoo issues relatively short Request Tokens from a limited
> character set to make them easy to type. We compensate for the short RTs by
> pairing them with long RTSecrets. If we were to implement the hybrid
> protocol, our hybrid RTs would be much longer than the regular OAuth RTs.
>
> We also believe that developers may inadvertently leak their Consumer
> Secrets. We're seeing lots of questions from developers who are trying to
> use OAuth from within Javascript and Flash, which implies that they're going
> to be leaking the secret to the browser. Developers may also reuse their
> website's Consumer Key into a downloadable client application.
>
> Allen
>
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Dirk Balfanz wrote:


On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <[EMAIL PROTECTED] 
> wrote:



In Section 10, and perhaps also in Section 12, the spec should
mention that because the hybrid protocol does not have a request
token secret, and because the user is never required to manually
type in the request token (unlike in OAuth), the hybrid Request
Token probably should be longer and harder to guess than the
standard OAuth Request Token. At least for our implementation, I'm
thinking that the hybrid RT == OAuth's RT+RTSecret.


But you need to have the consumer secret to exchange it, no? What if 
it were just a incrementing integer? What would the attack be?
Yes, the attacker would still need the Consumer Secret, however in 
vanilla OAuth, the attacker would need the Consumer Key, Consumer 
Secret, Request Token, and Request Token Secret. Because there's one 
less secret, the Access Token could be more vulnerable to hijacking from 
brute force attacks where RTs are just randomly scanned.


In our case, Yahoo issues relatively short Request Tokens from a limited 
character set to make them easy to type. We compensate for the short RTs 
by pairing them with long RTSecrets. If we were to implement the hybrid 
protocol, our hybrid RTs would be much longer than the regular OAuth RTs.


We also believe that developers may inadvertently leak their Consumer 
Secrets. We're seeing lots of questions from developers who are trying 
to use OAuth from within Javascript and Flash, which implies that 
they're going to be leaking the secret to the browser. Developers may 
also reuse their website's Consumer Key into a downloadable client 
application.


Allen


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Completing the SREG 1.1 specification

[Dick Hardt]

On 2-Dec-08, at 3:41 PM, Allen Tom wrote:
>
> We decided to build support for SREG before AX because SREG seems to  
> be
> more widely used, and also because SREG allows the RP to pass the  
> url to
> its privacy policy in the request. Strangely, AX does not have an
> interface for the RP to pass its privacy policy to the OP.

Not sure how we missed that feature in SREG. Our bad.

> Moving forward, we'd also like to support both SREG and AX, if AX is
> updated to allow the privacy policy url to be included in the request.

Looking at what needs to be addressed in AX. Good suggestion. Ties in  
with suggestions from Nat where the response with the privacy policy  
is returned all signed by the OP.

>
>
> I'd be happy to help contribute to SREG and AX specs if the owners of
> the spec would like me to.

please!

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Completing the SREG 1.1 specification

[Allen Tom]

Yahoo is currently testing SREG, and we'd like to see the 1.1 SREG draft 
updated to clarify any ambiguities before we're done testing. We'd also 
like to see the schema updated to include the user's profile pic.

We decided to build support for SREG before AX because SREG seems to be 
more widely used, and also because SREG allows the RP to pass the url to 
its privacy policy in the request. Strangely, AX does not have an 
interface for the RP to pass its privacy policy to the OP.  We have a 
mandatory requirement from our legal and privacy teams to be able to 
link to the RP's privacy policy on our OpenID approval page before 
sharing any user data with an RP.

We'd like SREG to be updated to enable the profile pic to be in the 
schema, and also any other cleanup that's needed for OpenID 2.0 OPs to 
support it.

Moving forward, we'd also like to support both SREG and AX, if AX is 
updated to allow the privacy policy url to be included in the request. 
Alternatively, OPs which support the OpenID/OAuth hybrid protocol can 
just tie the privacy policy to an OAuth consumer key, assuming that the 
OP requires pre-registered consumer keys.

I'd be happy to help contribute to SREG and AX specs if the owners of 
the spec would like me to.

Allen


David Recordon wrote:
> I certainly want to see us push the world to implementing AX instead  
> of SREG, though agree with Mart that there are existing  
> interoperability problems with SREG that would be nice to fix given  
> that large OPs are still implementing it in a broken fashion.  I'd see  
> no issue with including in the SREG spec that people really should go  
> use AX instead.
>
>
>   
>> On 28-Nov-08, at 11:28 PM, Martin Atkins wrote:
>>
>> 
>>>
>>> As long as folks still want to implement SREG, I think it's  
>>> beneficial
>>> to have a specification that actually works in practice, which the
>>> current draft does not.
>>>   

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs