Re: Authentication realm

On Dec 7, 2009, at 8:44 AM, Eran Hammer-Lahav wrote:
> 
>>> As currently defined, realm doesn't fully cover the use cases of the
>>> proposed Token scheme (OAuth WG). We will need to either redefine it,
>>> supplement it, or replace it. Either way, we need to know what is dictated by
>>> the HTTP authentication framework.
>> 
>> Could you elaborate on that?
> 
> The main idea behind the Token scheme [1] is to support multiple classes of credentials. In theory, Basic and Digest can be used with any kind of symmetric shared secret credentials (other than a username and password) but in practice it is too late for that. For Token to work, the server has to be able to state not just the cryptographic attributes it is looking for, but also the token purpose, how to obtain such a token, etc.
> 
> It is not clear to me that in such an arrangement, there is value in partitioning resource access at the resource. Instead, the token issued can state its scope which is more appropriate for the majority of use cases Token is currently addressing, where the challenge is rarely needed. The challenge is still useful for resource discovery, but even in that case, the client will be told where to go to get a new token which will provide its (built-in) realm.

Realm is useful for distinguishing multiple authentication
realms on the same server.  I don't see how that would change,
regardless of the new auth mechanism.  It is part of the
credential caching mechanism of clients.

BTW, I find it odd that token auth has

   10.4.  Plaintext Storage of Credentials

   When used with a symmetric shared-secret authentication method, the
   token shared-secret function the same way passwords do in traditional
   authentication systems.  In order to compute the signatures used in
   methods, the server must have access to these secrets in plaintext
   form.  This is in contrast, for example, to modern operating systems,
   which store only a one-way hash of user credentials.

   If an attacker were to gain access to these secrets - or worse, to
   the server's database of all such secrets - he or she would be able
   to perform any action on behalf of any resource owner.  Accordingly,
   it is critical that servers protect these secrets from unauthorized
   access.

I thought we learned that lesson a long time ago.  Why is it not
using a hash of the shared secret instead of the shared secret,
like how digest md5-sess uses H(user:realm:password)?

....Roy

Received on Monday, 7 December 2009 23:15:54 UTC