Re: [oauth] GData and multiple accounts

[Breno de Medeiros]

We plan to use 'claimed_id' information to auto-select the user in the
approval page for OpenID hybrid, and generalize it to OAuth2 if they support
 a similar mechanism to indicate the user.

Once we get this working on OpenID, I can look at if it would be appropriate
to define an xoauth_ parameter for OAuth 1.0/1.0a

On Wed, Aug 4, 2010 at 11:27, Chris Messina  wrote:

> This is a Google-specific request, but my initial reaction would be, no,
> it's not possible to bypass this screen since it's still up to the user's
> discretion to pick the account data they want to grant access to.
>
> Allowing a third-party to specify the account data that the user is
> granting access to seems to take away a necessary control from the user.
>
> That said, I'm sympathetic to the user experience hassle this adds to
> authorization flows, so there might be some way to optimize the dance.
>
> Chris
>
> On Wed, Aug 4, 2010 at 11:13 AM, PanosJee  wrote:
>
>> Hi guys, i am using the Python lib to access Gmail and Contacts. Is it
>> possible to bypass the screen that allows the user to select among
>> multiple google accounts. I already know the account he wants to
>> import so I ld like to display the Grant Access screen after the
>> redirection as some other apps do.
>>
>> Any hints?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OAuth" group.
>> To post to this group, send email to oa...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> oauth+unsubscr...@googlegroups.com 
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/oauth?hl=en.
>>
>>
>
>
> --
> Chris Messina
> Open Web Advocate, Google
>
> Personal: http://factoryjoe.com
> Follow me on Buzz: http://buzz.google.com/chrismessina
> ...or Twitter: http://twitter.com/chrismessina
>
> This email is:   [ ] shareable[X] ask first   [ ] private
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

[oauth] Re: Consideration about oauth_verifier

[Breno de Medeiros]

Hi Simone,

Yes, interception is possible. Note, however, that the URL to return
the user to is signed in the consumer's initial request, so it is not
possible to mis-direct the user. So to intercept the response the
attacker needs to perform a Man-in-the-Middle attack. Typical
protections against MitM can then be used (e.g., use SSL at the
provider and consumer endpoints).



On Fri, Sep 25, 2009 at 7:46 AM, Simone  wrote:
>
> Hi. I would ask you a thing about the unguessable parameter
> oauth_verifier.
> In the attack at the core 1.0 specification the intruder not have to
> intercept anything but only constructs a link for the victim.
> In the new version of the protocol core 1.0A, when the service
> provider redirects the user to the consumer with the parameter
> oauth_verifier, if an intruder intercepts this message with the
> oauth_verifier, since the message is in clear, cannot the intruder use
> the oauth_verifier and come back him to the consumer for continue a
> previous session of the protocol, realizing an attack similar to the
> that found in the core 1.0 specification? Is there the assumption that
> the message in the redirection (from the user to the consumer) is not
> intercepted?
> Sure the attack is more difficult than the first one because now are
> need some interceptions, but is possible, or not?
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Timing Attacks against OAuth implementations

[Breno de Medeiros]

I would note that this bug is not OAuth-specific but in principle
affects other protocols that perform signature validation via HMACs.

This is a good reason not to roll out new crypto code willy-nilly. If
you use a established crypto library then when people fix bugs
(possibly mitigating discovered attacks against other protocols), the
fix may protect your implementation as well.

On Fri, Aug 14, 2009 at 11:53 AM, Pelle Braendgaard wrote:
>
> This was posted yesterday about timing attacks when comparing digests
> as most of us do in our OAuth implementations.
>
> http://codahale.com/a-lesson-in-timing-attacks/
>
> The problem is not with the standard itself but with the
> implementations. Luckily it is pretty easy to fix.
>
> The above post provides us with fairly easy solutions for both Java
> and Python. I wrote a fix for Ruby, which I think should provide
> protection for it:
>
> http://github.com/pelle/oauth/commit/c867394b4b14bc893cc29fbb0b1b839066843b93
>
> We will probably do a ruby gem release shortly for this, but in the
> meantime feel free to use the gem from my oauth repository.
>
> It is not afaik esploitable without a fair bit of skill, but I believe
> it it is definitely exploitable.
>
> P
>
> --
> http://agree2.com - Reach Agreement!
> http://extraeagle.com - Solutions for the electronic Extra Legal world
> http://stakeventures.com - Bootstrapping blog
>
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Request for new Security Considerations text

[Breno de Medeiros]

I am not sure this is in any document. I have seen it being discussed
as part of the security considerations.

On Tue, May 12, 2009 at 11:48 AM, Eran Hammer-Lahav  wrote:
> Can you point to the specific text you are talking about?
>
>
>
> EHL
>
>
>
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of
> Breno
> Sent: Tuesday, May 12, 2009 8:21 AM
> To: oauth@googlegroups.com
> Subject: [oauth] Re: Request for new Security Considerations text
>
>
>
> One nit: I think the terminology 'mixed binding' conveys the opposite of
> what is intended. Mixed or mis-binding is an accurate description of
> possible errors with an early binding strategy. I suggest 'full binding'
> instead.
>
> On May 12, 2009 7:27 AM, "Eran Hammer-Lahav"  wrote:
>
>
> That is an implementation detail. I am not sure how helpful it would be to
> have a security consideration section about limiting the number of allowed
> token exchange requests for a single request token.
>
> EHL > -Original Message- > From: oauth@googlegroups.com
> [mailto:oa...@googlegroups.com] On...
>
>> Of Hubert Le Van Gong > Sent: Tuesday, May 12, 2009 3:26 AM > To:
>> oauth@googlegroups.com > Subject...
>
>> If I remember correctly, we also talked of recommending or mandating >
>> one-time request tokens. > ...
>
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth Core 1.0 Rev A, Draft 2

[Breno de Medeiros]

You have a XSRF vulnerability against your callback URL no?

Basically, you should set a cookie on the user with the request token
value before redirecting for authorization, and verifying that it
matches.

On Fri, May 8, 2009 at 6:44 PM, Manish Pandit  wrote:
>
>
>
> On May 8, 6:04 pm, Brian Eaton  wrote:
>>
>> Sweet.  Last time somebody said this it was late on a Friday, too, and
>> look how well that turned out. =)
>>
>> I'm pretty sure OAuth 1.0a isn't vulnerable to what you're describing,
>> but I can't explain why without a more detailed explanation of how
>> your attack works.  Can you break it down into a step-by-step "evil
>> user does X, good guy does Y" flow?
>
> Assumptions:
>
> 1. The provider requires a callback_url with get_request_token, signed
> per the 1.0a.
> 2. The provider returns an oauth_verifier along the blessed request
> token on the callback (if not oob) to the consumer upon user consent.
> 3. The consumer has a database table (or any other mechanism) to store
> a user identifier (user's identity at the consumer), request token and
> access token
> 4. The provider has a database table (or any other mechanism) to store
> the user identifier (user's identity at the provider), request token
> and access token
> 5. The endpoints are one time use only - so authorize_token and
> get_access_token can be called once and only once for a given token.
> 6. The victim consents to providing access to the consumer for his
> protected data.
> 7. The access token lives long enough for these steps (usually a few
> hours)
> 8. The request token lives long enough for steps 3 though 11.
>
> Flow:
>
> 1. Evil user (identity = eviluser) logs in to the consumer webapp.
>
> 2. Clicks a link to access protected resources on the provider
>
> 3. Consumer gets a request token per 1.0a (token1), and redirects the
> eviluser to provider's login page.
>
> 4. Consumer record says {userId=evilUser, requestToken=token1,
> accessToken=null}
>
> 5. Provider record says {userId = null, requestToken=token1,
> accessToken = null}
>
> 6. eviluser copy-pastes this link and sends it to the soon-to-be
> victim via IM to get everything done in the request token TTL which
> can be few minutes. Evil user does not even need to be online after
> this step.
>
> 7. The  soon-to-be victim get the IM, clicks on the link.
>
> 8. Everything checks out, the victim logs in to the provider with his
> credentials (gooduser). The provider updates the record at their end.
>
> 9. Provider record now says {userId=gooduser, requestToken=token1,
> accessToken=null}
>
> 10. Provider now generates an oauth_verifier (abcd). Appends it to
> oauth_token=token1 and calls back the consumer on the callback
> provider in step 3
>
> 11. The consumer gets the callback with the token and verifier. The
> record still says {userId=eviluser, requestToken=token1,
> accessToken=null}
>
> 12. The consumer tries to convert this token to access token, now that
> it has received the callback with a verifier. It may or may not store
> the oauth_verifier.  (In my provider implementation, I am not storing
> the verifier and relying completely on the signature verification)
>
> 13. The consumer per 12 creates a signed request (including the
> verifier) to request access token against the blessed request token.
>
> 14. The provider gets the request, and converts the requestToken to
> access token as everything seems to be alright. The provider record
> now says {userId=gooduser, requestToken=token1, accessToken=token2)
>
> 15. The provider returns the accesstoken to the consumer. Consumer
> record now says {userId=evilUser, requestToken=token1,
> accessToken=token2).
>
> 16. Now eviluser  logs in to consumer, accesses a protected endpoint
> (getAddressBook.do). Since the consumer already has an access token
> for evilUser (see the db record above), it sends the request to access
> protected resources.
>
> 17. The provider looks up the user who has that access token
> (gooduser, see db record above) and returns gooduser's addressbook to
> the consumer.
>
> 18. The consumer passes along the gooduser's addressbook to the
> eviluser.
>
> There you have it - I really really hope I am missing something here.
>
> Since the spec does not have any guidelines for the consumer (it
> should never do anyway), we cannot assume that the consumer is or is
> not linking identities and tokens in a particular fashion. Besides I
> think the whole scenario can be replicated without the record at the
> consumer too, but Friday 6:45P I am too fried to think further :(
>
> -cheers,
> Manish
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com

[oauth] Re: Confirm callback when getting access token

[Breno de Medeiros]

I do not think there is anything fundamentally wrong with James
proposal. However, I have not given it near the same level of scrutiny
that I did to the existing proposal. Plenty of eyes were intensely
focused on it during the week immediately after the advisory came out.
The net result is that the existing proposal was widely discussed and
has received 1000's of hours of total attention from developers and
security experts by now, from an implementation issues perspective
sure, but also critically from a security perspective.

On Wed, May 6, 2009 at 10:56 PM, Eran Hammer-Lahav  wrote:
> James, thanks for adding the proposal and offering deeper insight into its 
> details. I would like to ask you to add it to the wiki page so we have it 
> documented.
>
> I would like to ask people if they have strong views for or against this 
> proposal. So far a few people raised concerns which James tried to addressed, 
> but I have not heard from anyone who would like to advocate this as the 
> proposal patch. I think any proposal deserves to be considered, but we need 
> more people to advocate it for it to remain on the table.
>
> EHL
>
>
>
>> -Original Message-
>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>> Of Manger, James H
>> Sent: Wednesday, May 06, 2009 7:31 PM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: Confirm callback when getting access token
>>
>> Brian,
>>
>> There are two attacks: attacker gets victim's access; and login CSRF.
>>
>> They are distinct attacks, causing different damage, and with different
>> defences -- but they are both sort of related to session fixation.
>> Consequently, I find the term "session fixation" a bit ambiguous in
>> these discussions.
>>
>> The first attack is the OAuth-specific issue that attention is focused
>> on.
>>
>> Callback-with-request-token and callback-with-access-token both address
>> the first attack. Neither addresses login CSRF.
>>
>> A Referer check at the callback URI is one way to combat login CSRF
>> against the callback URI. I wasn't suggesting that this defeats the
>> first attack as well.
>>
>> I have earlier suggested a Referer check *at the authorization URI*
>> could combat the first attack. I still think that could be quite an
>> effective temporary fix, though Allen Tom suggested issues with social
>> networking sites that I haven't fully groked.
>>
>>
>> I don't think encoding all state in the callback URI implies a
>> vulnerability to session fixation. There is usually no session yet.
>> Encoding all state in the callback URI might make it more important to
>> explicitly address login CSRF, but they are still separate issues.
>>
>> Options for client-side state with 1.0 include (at least):
>> * callback URI
>> * cookies
>> * javascript variables
>> I don't want to remove any option if we don't have to. JavaScript
>> variables presumably fail on clients that disable JavaScript. Cookies
>> might be blocked by some clients, don't work across domains, and have
>> their own issues.
>>
>>
>> Breno suggested that by removing the callback URI as an option for
>> storing state (by adopting callback-with-request-token), developers are
>> more likely to choose a state management approach that accidentally
>> prevents login CSRF.
>>
>> I really like the idea of making the easiest option for developers the
>> secure choice. However, I feel that while callback-with-request-token
>> might make the easiest *remaining* option a secure choice, it only does
>> so by eliminating other options that can be easier and still be secure.
>> [What is easiest varies with circumstance, of course]
>>
>>
>> James Manger
>> james.h.man...@team.telstra.com
>> Identity and security team — Chief Technology Office — Telstra
>>
>> -Original Message-
>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>> Of Brian Eaton
>> Sent: Thursday, 7 May 2009 3:44 AM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: Confirm callback when getting access token
>>
>>
>> On Tue, May 5, 2009 at 9:34 PM, Manger, James H
>>  wrote:
>> > I would prefer to fix OAuth security issue 2009-1 without
>> unnecessarily preventing
>> > state-management options that previously worked, and without
>> requiring cookies where
>> > they were not previously necessary.
>>
>> I'm pretty sure that any client that encodes all state in the callback
>> URL is still vulnerable to session fixation.  You mentioned using
>> referer or origin HTTP headers to prevent XSRF of the callback URL,
>> but those don't actually work to prevent the session fixation attack.
>> (Referer and Origin will always point to the SP.)
>>
>> (Nit: the protocol doesn't actually require cookies.  Other types of
>> client-side state (javascript variables for web browsers, disk or
>> memory storage for installed apps) are perfectly viable.)
>>
>>
>>
>>
>
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-

[oauth] Re: Confirm callback when getting access token

[Breno de Medeiros]

Good point. This alternate solution is less backward compatible.

On May 5, 2009 7:15 PM, "Josh Roesslein"  wrote:

One issue that arises is now the SP has no way to tell if we are using 1.0
old flow or the new flow.The SP will not know which one is being used until
the consumer asks for the access token. So how will we know if the callback
should use the old flow's format or the new flow w/ verifier?

We would either have to increment the wire version OR the SP would have to
use different end points for the two flows.

example: http://www.test.com/oauth/1.0a OR 1.0/request

On Tue, May 5, 2009 at 9:06 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote: > > [I sa...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Confirm callback when getting access token

[Breno de Medeiros]

James, you made the best argument (in my view) of why we should stick
with the existing proposal, namely that the easiest way to preserve
statelessness is to implement a measure that results in XSRF
protection side effects.

On Tue, May 5, 2009 at 6:21 PM, Owen Evans  wrote:
> true... must be in an after lunch stupor.
> O
>
> 2009/5/6 Manger, James H 
>>
>> I think it does solve the problem, Owen.
>>
>>
>>
>> The SP redirects B to the malicious callback – and remembers that this
>> malicious callback is associated with this request token & verifier.
>>
>> When the consumer asks for an access token the consumer will include the
>> original callback. The SP notices that the two callbacks are different and
>> rejects the access token request.
>>
>>
>>
>> James Manger
>> james.h.man...@team.telstra.com
>> Identity and security team — Chief Technology Office — Telstra
>>
>> 
>>
>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of
>> Owen Evans
>> Sent: Wednesday, 6 May 2009 11:09 AM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: Confirm callback when getting access token
>>
>>
>>
>> Doesn't really solve the problem:
>>
>>
>>
>> (malicious) User A gets the "Authorisation URL" from an application that
>> has received a request token.
>>
>> User A replaces call-back parameter with malicious or spoof site instead
>> of original call-back
>>
>> User A tricks User B (Innocent) into logging into SP with
>> incorrect call-back parameter.
>>
>> User B is sent to malicious site which save the verification code.
>>
>> User A gets verification code from malicious site and uses it to redirect
>> to original consumer application
>>
>> User A now has access to User B's resources.
>>
>>
>>
>> O
>>
>
>
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Confirm callback when getting access token

[Breno de Medeiros]

>
> The Consumer App includes the Callback URI when obtaining an Access Token,
> instead of including the Callback URI when obtaining a Request Token.
>
> The Service Provider checks that the Callback URI in the request for an
> Access Token matches the Callback URI to which the authorizing user was
> redirected.
>
> The significant advantage of this approach is that the Consumer App knows
> the Request Token and Secret before they specify the Callback URI so they
> can encode state into the callback and operate in a stateless manner – which
> is important for scalability.

The request token can be stored in a cookie or some other parameter
that provides XSRF protection vis-a-vis the callback URL. This allows
the consumer to remain stateless by doing the right thing.

>
> An advantage of this approach for the Service Provider is that there is no
> extra state that has to be maintained between the Request Token and
> Authorization steps so the SP’s Request Token format should not need to
> change to maintain stateless operation.
>

This does not have to change. The SP can encode the callback URL in
the request token itself.

>
>
> I believe Consumer Apps can operate in a stateless manner with OAuth Core
> 1.0 so it would be a significant disadvantage to break this ability in a
> security fix. My guess is that it would require very substantial changes to
> a Consumer App’s architecture if it had to switch from a stateless to a
> statefull mode to support a security fix.

There is no need for such radical changes as described above.

>
>
>
> The Callback URI still appears in the authorization step, but changing it
> does not help an attacker since that would cause the subsequent request to
> obtain an Access Token to fail.

Possibly. But we would have to think carefully about that.

>
>
>
>
>
>
>
> 6.1.1. Consumer obtains a Request Token – UNCHANGED from 1.0
>
>
>
> 6.1.2. Service Provider issues an unauthorized Request Token – UNCHANGED
> from 1.0
>
>
>
> 6.2.1. Consumer directs the User to the Service Provider – UNCHANGED from
> 1.0
>
>
>
> 6.2.2. Service Provider authenticated the User and obtains consent – change
> warning text in some situations
>
>
>
> 6.2.3. Service Provider directs the user back to the Consumer – insert
> “verifier” into callback, or display “verifier”
>
>
>
> 6.3.1. Consumer requests an Access Token – CHANGED to include Callback URI
>
>
>
> 6.3.2. Service Provider grants an Access Token – UNCHANGED from 1.0 at the
> protocol layer, but the SP performs an extra check (that the Callback URI
> matches) before responding
>
>
>
>
>
>
>
> The OAuth wiki (http://wiki.oauth.net/OAuth-Session-Fixation-Advisory)
> compares proposed solutions with 10 questions. 9 answers for this proposal
> (callback with access token request) are the same as the “signed callback
> URLs” (callback with request token request) solution. The only difference is
> supporting a smooth upgrade path from 1.0 to the fixed protocol. This
> proposal can certainly support a smooth upgrade path, but it cannot use the
> presence of oauth_callback when obtaining a Request Token to indicate
> support for the new version. Any other indication would do. A different
> Request Token URI is one option.
>
>
>
>
>
>
>
> James Manger
>
> james.h.man...@team.telstra.com
>
> Identity and security team — Chief Technology Office — Telstra
>
>
>
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Desktop Application Callback Value

[Breno de Medeiros]

Version 3, where the string literal is supposed to be interpreted as
"manual entry or out-of-band" exchange of the callback token.

Version 1 is already supported. There is interest to support some form
of manual entry (for instance, SPs could give less stern warnings for
such desktop apps).


On Fri, May 1, 2009 at 1:43 AM, Blaine Cook  wrote:
>
> We need to gain some consensus around the value (or lack thereof) that
> should be used for the oauth_callback parameter that is sent from the
> consumer to the service provider when obtaining the request token in
> the new flow. Our options:
>
> 1. None. Applications that cannot receive callbacks (or that have
> static callback endpoints) should be configured as such in an
> out-of-band flow, along with the service provider issues the consumer
> key and secret.
> 2. String literal "none"
> 3. String literal, other than "none"
>
> I have omitted "oob" explicitly since it seems as though there was a
> lot of confusion around it. However, there is the option for a
> different string literal. I'd also like to hear from library authors
> whose voices have not been present in the discussions over the past
> week. Please indicate your preferred option as soon as possible.
>
> b.
>
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Version Preference

[Breno de Medeiros]

Option 1. The version number change will not make any task easier, and
will just complicate developers' lives by having to configure 2
libraries instead of 1.

On Fri, May 1, 2009 at 8:54 AM, Jesse Myers  wrote:
>
> Option 3
>
> On Fri, May 1, 2009 at 8:29 AM, Jim Meyer  wrote:
>> +1 ... er, +.1
>>
>> --j
>>
>> On May 1, 2009, at 7:55 AM, "Matt Sanford"  wrote:
>>
>>>
>>> Option 3 … that's what versions are for, incrementing.
>>>
>>> On May 1, 2009, at 1:25 AM, Blaine Cook wrote:
>>>

 We need to build some consensus around the version preference. As I
 see it, there are several options:

 1. "1.0 Rev A" with no version string change (i.e.,
 oauth_version=1.0)
 2. "1.0a" (with oauth_version=1.0a)
 3. "1.1"

 Please indicate your support for one of these options, and try to
 refrain from arguing your case here. The other thread remains open
 for
 that purpose. I would especially like to hear from library
 implementers here, and others who have not voiced their opinions in
 the other threads.

 b.

>
>>>
>>>
>>> >
>>
>> >
>>
>
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth Core 1.0 Rev A, Draft 1

[Breno de Medeiros]

Proposed Google searches:

jar+version+nightmare

dll+version+nightmare

+version+nightmare


On Thu, Apr 30, 2009 at 7:17 PM, Josh Roesslein  wrote:
> How will calling this 1.1 slow down the upgrade process? All libraries need
> to change to cover the new spec, so it doesn't matter what we call it.
> SP's can still support older clients by running 1.0 and 1.1 specs. This
> allows for older clients to perform upgrades to 1.1 before cutting them off.
> SP checks the oauth_version string in the request token request and then
> uses the correct library version to complete the flow.
>
> On Thu, Apr 30, 2009 at 8:55 PM, Breno de Medeiros  wrote:
>>
>> Since there is no discovery supported in OAuth, even if the version is
>> incremented, there is no way to know if an SP or consumer has upgraded
>> without actually running the flow.
>>
>> If you increment the version number, you will have to make a lot more
>> code changes in each library to configure behavior, and will slow down
>> adoption of the fix and complicate a transitional period where folks
>> might want to support the older flow with some mitigation
>> features/stronger warnings until it is safe to break compatibility.
>>
>> If we want better security, we go with the option that moves us
>> forward fastest. The easiest way to abandon 1.0 flow is to get
>> everybody upgraded to 1.0A. And developers are complaining that
>> incrementing the version number will slow things down.
>>
>> On Thu, Apr 30, 2009 at 6:26 PM, David Parry  wrote:
>> > seriously, I don't understand the reluctance to increment
>> > oauth_version. The new implementation is going to require work from
>> > both SPs and consumers, and neither is really going to know if other
>> > has upgraded without actually running the flow. At least, by
>> > incrementing the version, both the SP and the Consumer definitively
>> > know the required flow.
>> >
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>>
>>
>
>
> >
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth Core 1.0 Rev A, Draft 1

[Breno de Medeiros]

Since there is no discovery supported in OAuth, even if the version is
incremented, there is no way to know if an SP or consumer has upgraded
without actually running the flow.

If you increment the version number, you will have to make a lot more
code changes in each library to configure behavior, and will slow down
adoption of the fix and complicate a transitional period where folks
might want to support the older flow with some mitigation
features/stronger warnings until it is safe to break compatibility.

If we want better security, we go with the option that moves us
forward fastest. The easiest way to abandon 1.0 flow is to get
everybody upgraded to 1.0A. And developers are complaining that
incrementing the version number will slow things down.

On Thu, Apr 30, 2009 at 6:26 PM, David Parry  wrote:
> seriously, I don't understand the reluctance to increment
> oauth_version. The new implementation is going to require work from
> both SPs and consumers, and neither is really going to know if other
> has upgraded without actually running the flow. At least, by
> incrementing the version, both the SP and the Consumer definitively
> know the required flow.
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth Core 1.0 Rev A, Draft 1

[Breno de Medeiros]

Yes, it does.

If a server receives a request token request from a client that does
not include a callback_url, the server can respond with a 400 (Bad
Request) and, if you want to be more helpful say something in the body
like: "Incompatible OAuth flow. This server only supports 1.0a, see
"

On Thu, Apr 30, 2009 at 5:59 PM, David Parry  wrote:
> I don't have a problem with that, it makes perfect sense.
>
> But the proposed spec doesn't provide any method by which to deprecate
> the old broken 1.0 functionality and convey that to the consumer that
> is making the request.



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth Core 1.0 Rev A, Draft 1

[Breno de Medeiros]

On Thu, Apr 30, 2009 at 9:44 AM, Eran Hammer-Lahav  wrote:
> Present with empty value - display verifier to user and require to exchange 
> tokens

I do not see how an empty value is an improvement from a non-valid
URI. It may not cause problems, but we don't know that. Let's play
safe and if people are unhappy with 'oob', then say 'outofband' or
something.

Not included in request token request seems not an option for clients
that expect a verifier, if we expect SPs will have a period of
handling both flows.

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Signature Methods extension

[Breno de Medeiros]

CRC-32? Do we need OAuth for smart price labels?

On Wed, Apr 29, 2009 at 2:57 PM, Eran Hammer-Lahav wrote:

>  When we wrote OAuth, there was some resistance to dropping MD5 and CRC32.
> That wiki language was the compromise, with the plan to write an extension
> for those. Since no one asked for it since then, it was never written.
>
> EHL
>
>
>
> On 4/29/09 6:18 AM, "Simone Tripodi"  wrote:
>
>
>
> Ciao Luca :)
> thanks for your reply, since in the wiki page they say
>
> "We agreed to drop MD5, CRC32, and the likes from the spec due to
> security concerns. However, those signing algorithms should still be
> documented and will be supported by vendors so we might as well
> provide a consistent way of using them."
>
> I was looking for some documentation just to have a look at those methods.
> Thanks!!!
> Simone
>
> On Wed, Apr 29, 2009 at 2:37 PM, Luca Mearelli 
> wrote:
> >
> > hi,
> >
> > On Wed, Apr 29, 2009 at 11:56 AM, Simone Tripodi
> >  wrote:
> >> I'd like to know more about signature methods extension mentione on
> >> the wiki page:
> >>
> >> http://wiki.oauth.net/SignatureMethods
> >
> > section 9 in the spec. defines the requirement for signatures but does
> > not mandate a specific signature method it rather describes an
> > algorithm to define the text to be signed (the "signature base
> > string") and "defines three signature methods: HMAC-SHA1, RSA-SHA1,
> > and PLAINTEXT, but Service Providers are free to implement and
> > document their own methods." i.e. Some service provider implementer
> > could choose to build his own signature method (e.g. using different
> > crypto) as long as it properly documents it but I honestly can't
> > remember any SP that has done so...
> >
> > anyhow it seems that the wiki page was calling for documenting in a
> > standard way the specific signature methods developed by the various
> > SPs (i noticed that the wiki page pre-dates the "OAuth Core 1.0" spec
> > which was published on  Dec 4th 2007).
> >
> > ciao,
> > Luca
> >
> > >
> >
>
>
>
> --
> http://www.google.com/profiles/simone.tripodi
>
>
>
>
> >
>


-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: One-time only token exchange?

[Breno de Medeiros]

Sometimes users may hit the 'reload' button in the consumer page and that
may result in the request token swap being sent twice. So, this implies a
requirement on consumers to immediately redirect users to a different page
so that the "back" and "reload" buttons won't re-submit the request.

In practice, with the new changes, it would be hard for an attacker to get
hold of the user's response within a short time frame. Since the request
tokens are single time use already, I believe there is no reason for
additional spec changes, though probably a discussion on a security
considerations section of the spec (which should be moved from appendix to
main document) may well be indicated.

On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver  wrote:

> Actually, I think it's a pretty small change to the spec.
>
> In section 6.3.2 Service Provider Grants an Access Token (
> http://oauth.net/core/1.0/#auth_step3), it says:
>
> The Service Provider MUST ensure that:
>
>- The request signature has been successfully verified.
>- The Request Token has never been exchanged for an Access Token.
>- The Request Token matches the Consumer Key.
>
> ...
> If the request fails verification or is rejected for other reasons, the
> Service Provider SHOULD respond with the appropriate response code as
> defined in HTTP Response Codes (HTTP Response 
> Codes)
> .
>
>
> Perhaps an updated version could say something like (changes in red):
>
>  The Service Provider MUST ensure that:
>
>- The request signature has been successfully verified.
>- The Request Token has never been exchanged for an Access Token.
>- There have been no prior attempts to exchange this Request Token for
>an Access Token.
>- The Request Token matches the Consumer Key.
>
> ...
> If the request fails verification or is rejected for other reasons, the
> Service Provider SHOULD invalidate or delete the request token and respond
> with the appropriate response code as defined in HTTP Response Codes (HTTP
> Response Codes) .
>
>
>
>
> On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver wrote:
>
>>
>> Hmm... I feel like this has been lost in all the hubbub about
>> callbacks.
>>
>> I strongly advocate saying something in the spec about making the
>> token exchange (access token endpoint) one-time use only.
>>
>> By one-time only, I mean that the first time there is an attempt to
>> exchange a request token for an access token, if the request token has
>> not been authorized, then that request token should be marked as
>> invalid. This will make a session fixation attack nearly impossible
>> without a callback.
>>
>> If a service provider allows multiple attempts to exchange the request
>> token a callback is not even necessary for the attack to work! The
>> attacker must only keep trying to exchange the token.
>>
>> I know it's up to the service provider to implement one-time only
>> token exchange, but putting it in the documentation (and libraries)
>> will make it much easier for service providers to do the right thing.
>>
>> Am I missing the discussion about this? Is it on the wiki and I just
>> can't find it? Or is everyone in agreement that this should be added
>> to the docs?
>>
>> Thanks,
>> Leah
>>
>>
>
> >
>


-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth Security Advisory

[Breno de Medeiros]

We have thought about it and decided it was a bad idea, because:

1. If the consumer uses RSA keys, then the provider cannot sign using them.

2. If the consumer uses HMAC keys, then the provider would be signing
using the same key. It is generally consider a bad idea in
cryptographic protocols to have two different parties use the same key
for the same purpose (e.g., sign). It allows for a class of attacks
called reflection attacks.


On Thu, Apr 23, 2009 at 9:25 AM, Shan  wrote:
> What if the callback URL is signed on the provider's end using the
> consumer's secret key? The drawback is it puts the burden on the
> consumer to close the security hole by checking the signature, and as
> such the provider has no way of knowing if an application is secure or
> not.



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth Security Advisory

[Breno de Medeiros]

Not necessarily. The provider builds the request_token, so it could
simply include the callback_url in the request_token. If it does so,
it must authenticate it (e.g., HMAC with a key known _only_ to the
provider) so that an attacker cannot tamper and modify it.

On Thu, Apr 23, 2009 at 9:23 AM, pkeane  wrote:
> Does this add the extra burden on the Provider of maintaining state
> between A & C (i.e., being able to "remember" callback from A)?
> Currently, it is the Consumer secret that ties these interactions
> together.  Again it is addressing the need to connect the action/user
> in A with the action/user in C -- to "mix it in" with the out-of-band
> understanding established in the consume secret.



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: [OpenID] Can we make a seamless OpenID mobile experience?

[Breno de Medeiros]

No, this is not OTP. OTP requires you to enter a new code every time.
OAuth enables long-lasting or ever-lasting secure associations
(launched from a one-time-user, setup-time-entered-only secret). This
is not old OTP raising its head, it is very similar to current
industry-standard ways to associate devices (again, analogy with
bluetooth pairing).

On Fri, Apr 10, 2009 at 4:37 PM, Peter Williams  wrote:
> we surely we not are heading back to one time passwords, are we?
>
> Otp is where websso started over decade ago, as the rsa/securid inter domain 
> cookie! Plugin an nsapi in the otp verifing site, plug another 
> nsapi/isapi/servlet on the other sites which had no agent to verify otps, 
> create an artifact backchannel to create the target cookie subverting the 
> sandbox, one gets saml, and then openid...
>
> -Original Message-
> From: Breno de Medeiros 
> Sent: Friday, April 10, 2009 2:52 PM
> To: Deron Meranda 
> Cc: OAuth ; OpenID List 
> Subject: Re: [OpenID] Can we make a seamless OpenID mobile experience?
>
>
> Reposting this to OAuth, since they did not like my previous attempts.
>
> On Fri, Apr 10, 2009 at 2:09 PM, Breno de Medeiros  wrote:
>> Actually, the subversion client fits reasonably well in this paradigm:
>>
>> 1. The shell interface has a convenient mechanism to accept variable
>> input. So the choice of entering a password there.
>>
>> 2. The fact that the password does not get exchanged for another token
>> (single-user vs. pairing) is a consequence here of the fact that
>> subversion clients do not support OAuth; and the shell interface is a
>> reasonably convenient mechanism to enter long, strong secrets
>> (cut-and-paste from SVN server UI to shell client).
>>
>> In general, the human-to-device channel cannot conveniently accept
>> large secrets (the svn client example is an exception in this setting)
>> and therefore you need a shorter, single-use secret to leverage a
>> pairing of stronger crypto token. The OAuth protocol effectively gives
>> you this pairing.
>>
>> In general, the model of single-use code to be leveraged as a 'request
>> token secret' and the full OAuth exchange give in general a mechanism
>> that is both more usable (because requiring users to enter short
>> secrets) and  more secure (because it uses signatures for fetching
>> data instead of playing the same secret over what may be insecure
>> connections).
>>
>> On Fri, Apr 10, 2009 at 1:55 PM, Deron Meranda  
>> wrote:
>>> On Fri, Apr 10, 2009 at 3:34 PM, Breno de Medeiros  wrote:
>>>> The idea is to use a single-use code of some kind that works as a
>>>> password substitute (since the user does not have a password at the
>>>> site because he/she signs in using OpenID), followed by the
>>>> installation of a longer-lived token on the device. Think about
>>>> bluetooth pairing of devices as the basic paradigm.
>>>
>>> This is not just a mobile or device issue.  I do something similar
>>> now, for example, to support Subversion version control.  The client
>>> is typically a Unix command line, and the communications is HTTPS +
>>> DAV.  No browser there, and probably not even a GUI.
>>>
>>> Basically, my RP (which hosts subversion among other things) issues a
>>> single-purpose password for a user once they are authenticated via
>>> OpenID.  Then, just for the subversion/DAV portion of the website's
>>> URL space, I allow standard HTTP authentication.
>>>
>>> Also for subversion, most clients will try to "remember" the password
>>> once a DAV connection is configured for a local workspace.  So as not
>>> to break that, the password (which my RP picks) should not readily
>>> change.  This password is single-purpose, not single-use---which would
>>> be prohibitively frustrating for the user in this case.
>>>
>>> If your RP has it's own user ids; you can store your subversion
>>> passwords easily enough.  If not, then you can use something like an
>>> HMAC hash of the claimed_id, using a secret key, to generate the
>>> passwords for each user.  You also probably want to use some sort of
>>> hash on the claimed_id to generate the usernames (as would go in
>>> change lists, etc.); since arbitrary URLs are not syntactically
>>> suitable for subversion "users".
>>>
>>> Since my RP generates these passwords rather than the user picking
>>> them, they can be quite strong.  Also I don't have to worry about the
>>> user forgetting them and 

[oauth] Fwd: [OpenID] Fwd: [OpenID board] Question on implementation of OAUTH/OpenID for Set-top-box

[Breno de Medeiros]

Google's public research on OAuth and OpenID, which deals with many
issues of interest to the developer community in this are, in
particular user experience issues, is available at
http://sites.google.com/site/oauthgoog/

In particular, the following link is of interest to you:

http://sites.google.com/site/oauthgoog/UXFedLogin/nobrowser

Significant changes to that site are also announced in the blog
http://oauthgoog.blogspot.com/

Cheers,

--Breno

On Fri, Apr 10, 2009 at 11:47 AM, David Recordon  wrote:
> Hey Kamal,
> I'm forwarding your email to both the OpenID General and OAuth mailing
> lists.
> Cheers,
> --David
>
> Begin forwarded message:
>
> From: Kamal Mehta 
> Date: April 10, 2009 12:30:31 AM PDT
> To: bo...@openid.net
> Subject: [OpenID board] Question on implementation of OAUTH/OpenID for
> Set-top-box
> Reply-To: bo...@openid.net
> Hi,
>
> We are evaluating the integration of OpenID/OAUTH for our clients so that
> there could be a seamless user experience of Authentication on
> Playstation/Set-top-box. In due course we investigated it a bit and found
> that OpenID/OAUTH 2.0 follows a redirection model FROM Relying Party TO
> OpenID Provider through the UserAgent, which happens to be browser in all
> example implementation we have seen.
>
>  We have quick question, As described we are using Blue-Ray players which
> lacks the ability of having state-of-the-art browsers, is there any
> possibility of implementing OpenID and OAUTH w/out going thru browser route
> of redirection, such as any direct API call to get an authentication of
> user? Is it even feasible?
>
>  Are there any implementations done for Set-Top-Box by any other company we
> could leverage some design discussions?
>
>  Appreciate your early response.
>
>  Thanks in advance.
>
> --
> Regards,
> Kamal Mehta
> http://www.linkedin.com/in/kamalmehta
>
> ___
> board mailing list
> bo...@openid.net
> http://openid.net/mailman/listinfo/board
>
>
> ___
> general mailing list
> gene...@openid.net
> http://openid.net/mailman/listinfo/general
>
>



--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: [OpenID] Can we make a seamless OpenID mobile experience?

[Breno de Medeiros]

Reposting this to OAuth, since they did not like my previous attempts.

On Fri, Apr 10, 2009 at 2:09 PM, Breno de Medeiros  wrote:
> Actually, the subversion client fits reasonably well in this paradigm:
>
> 1. The shell interface has a convenient mechanism to accept variable
> input. So the choice of entering a password there.
>
> 2. The fact that the password does not get exchanged for another token
> (single-user vs. pairing) is a consequence here of the fact that
> subversion clients do not support OAuth; and the shell interface is a
> reasonably convenient mechanism to enter long, strong secrets
> (cut-and-paste from SVN server UI to shell client).
>
> In general, the human-to-device channel cannot conveniently accept
> large secrets (the svn client example is an exception in this setting)
> and therefore you need a shorter, single-use secret to leverage a
> pairing of stronger crypto token. The OAuth protocol effectively gives
> you this pairing.
>
> In general, the model of single-use code to be leveraged as a 'request
> token secret' and the full OAuth exchange give in general a mechanism
> that is both more usable (because requiring users to enter short
> secrets) and  more secure (because it uses signatures for fetching
> data instead of playing the same secret over what may be insecure
> connections).
>
> On Fri, Apr 10, 2009 at 1:55 PM, Deron Meranda  
> wrote:
>> On Fri, Apr 10, 2009 at 3:34 PM, Breno de Medeiros  wrote:
>>> The idea is to use a single-use code of some kind that works as a
>>> password substitute (since the user does not have a password at the
>>> site because he/she signs in using OpenID), followed by the
>>> installation of a longer-lived token on the device. Think about
>>> bluetooth pairing of devices as the basic paradigm.
>>
>> This is not just a mobile or device issue.  I do something similar
>> now, for example, to support Subversion version control.  The client
>> is typically a Unix command line, and the communications is HTTPS +
>> DAV.  No browser there, and probably not even a GUI.
>>
>> Basically, my RP (which hosts subversion among other things) issues a
>> single-purpose password for a user once they are authenticated via
>> OpenID.  Then, just for the subversion/DAV portion of the website's
>> URL space, I allow standard HTTP authentication.
>>
>> Also for subversion, most clients will try to "remember" the password
>> once a DAV connection is configured for a local workspace.  So as not
>> to break that, the password (which my RP picks) should not readily
>> change.  This password is single-purpose, not single-use---which would
>> be prohibitively frustrating for the user in this case.
>>
>> If your RP has it's own user ids; you can store your subversion
>> passwords easily enough.  If not, then you can use something like an
>> HMAC hash of the claimed_id, using a secret key, to generate the
>> passwords for each user.  You also probably want to use some sort of
>> hash on the claimed_id to generate the usernames (as would go in
>> change lists, etc.); since arbitrary URLs are not syntactically
>> suitable for subversion "users".
>>
>> Since my RP generates these passwords rather than the user picking
>> them, they can be quite strong.  Also I don't have to worry about the
>> user forgetting them and getting locked out; since the user can just
>> login via OpenID and then view the password when needed.
>>
>> For the end user, they will have to login via OpenID at least once, to
>> learn what their subversion username/password is.  Then they can use
>> subversion in the normal way, without OpenID.
>>
>> You can do additional security checks if you want.  Such as only
>> allowing the subversion password to work if a (relatively recent)
>> OpenID session has been created from the same location.
>>
>>
>> Granted, this puts a lot more work on the RP and it's not seamless.
>> But it is doable, and doesn't generate a mass of rarely-used
>> complexity in the OpenID protocol itself, or a rewrite of lots of
>> applications that know how to do standard HTTP authentication.
>>
>> --
>> Deron Meranda
>>
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---