Re: [OAUTH-WG] "shared symmetric secret"

On 7/13/10 10:25 AM, "John Kemp" <john@jkemp.net> wrote:

> On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
> 
>> I am ok replacing it with Oacts as a password¹.
> 
> An access token is something used by the server to decide whether a request is
> authorized. Although it may also be used for authenticating the request(er),
> it's purpose is to authorize the request.

It is used to authenticate the *request*, it is used in the same manner
other HTTP authentication schemes operate, and it has the same behavior as a
password (security wise: plain-text storage on the client side, can be
phished, usable by any bearer).

> In the "bearer token" case (and even over SSL unless client certs are used),
> the token clearly SHOULD NOT be used as a password. Rather, authentication
> should be performed by some other mechanism, unrelated to the token itself
> (such as an HMAC, or via client-certificate SSL/TLS, or even via an actual
> username/password)

OAuth only includes the "bearer token case". There are no other cases
specified.

> I would be very unhappy if we equated access tokens with passwords.
> 
> I agree with Dirk that "capability" is a more expressive phrase than either
> "shared secret" or "password".

Expressive to you and people well-versed in security theory. It means
nothing to a casual reader. The token definition includes the term, but in
this section, it is referring to how an access token is used, and it is used
just like a password.

For better or worse, we turned the 1.0 access token into a 2.0 password.

EHL

> Regards,
> 
> - johnk
> 
>> 
>> EHL
>> 
>> 
>> On 7/13/10 8:55 AM, "Dirk Balfanz" <balfanz@google.com> wrote:
>> 
>> 
>> 
>> On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav <eran@hueniverse.com>
>> wrote:
>> From the client's perspective, they are 'shared symmetric secrets' because
>> the client has to store them as-is and present them as-is. The act exactly
>> like passwords. I added that text to make that stand out.
>> 
>> When using passwords, the server doesn't need to store them in plain-text
>> either (e.g. uses a way one hash).
>> 
>> That's why we don't call passwords "shared symmetric secrets", either. The
>> verifier of a passwords can verify it without knowing the secret. In that
>> sense, it's not "shared" with the verifier.
>> 
>> I would like the specification to make it clear that bearer tokens are only
>> secure while they remain *secret* and that *anyone* holding them can gain
>> full access to what their protect.
>> 
>> I think the word "capability" expresses that better than the word "shared
>> secret".
>> 
>> Dirk.
>> 
>> 
>> EHL
>> 
>> On 7/12/10 10:39 PM, "Brian Eaton" <beaton@google.com> wrote:
>> 
>>> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5
>>> 
>>> Calling access tokens "shared symmetric secrets" is misleading,
>>> because if they are implemented well the authorization server and
>>> protected resource do not store a copy of the secret.
>>> 
>>> Instead they store a one-way hash of the token.  Or they verify the
>>> token cryptographically.  Under no circumstances do they need to store
>>> a copy.
>>> 
>>> I'd suggest the following language:
>>> 
>>> "Access tokens are bearer authentication tokens or capabilities."
>>> 
>>> Cheers,
>>> Brian
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 