Re: [sasl] draft-ietf-sasl-scram-11: why don't include the authentication identity in the stored key?

[Simon Josefsson <[e-mail]>]

Jehan Pagès <[e-mail]> writes:

> Hi,
>
> 2010/6/22 Alexey Melnikov <[e-mail]>:
>> Jehan Pagès wrote:
>>> But if the username was included in the StoredKey algorithm (for
>>> instance instead of salting the password only, you could salt
>>> [authentication identity + UTF8NUL + password]), noone having the
>>> stored key (whether the server itself or someone having gained access
>>> to it on the user's computer for instance) could use it to access any
>>> service other than the one it was stored for, EVEN IF this other
>>> service has the same salt and iteration count by some extraordinary
>>> chance, unless the same authentication identity is also used on both
>>> service (which might be improbable, though not impossible, as such
>>> identity often include a service domain).
>>>
>>> Isn't it better for security (though I agree that the chances of
>>> having same salt and iteration count are weak, here they would be even
>>> weaker)? Moreover in my opinion, associating the
>>> username/authentication identity and the password seems a nicer design
>>> (by including them both into the Stored key).
>>>
>>
>> I think you are right about security aspect of this. What you suggest was
>> done for DIGEST-MD5. The problem with that is that any change to the
>> authentication identity invalidates the hash containing it, so sysadmins
>> can't rename the user without also resetting the corresponding password.
>> Authentication identity changes is a sufficiently important problem for big
>> enterprise and university deployments, so it was decided that it was more
>> important to make sysadmin job easier than the security aspect.
>>
>
> I understand the argument. So it seems this "issue" has indeed been
> already thought of. Is it so common to massively change authentication
> identities in a running system?

Yes.  I've designed a proprietary implementation which also hashed the
username in the server-side hashed key, and deployment has been a pain
because administrators do want the ability to move "password-hashes"
between usernames.  I agree with you that allowing this weakens the
security somewhat, but practical matters appears to be more important.
I don't view it as a significant security problem.

> Because considering that many users use the same password everywhere,
> here this stored key really makes me think of an universal key which,
> once acquired, enter any system whatever the login name or the service
> is (no authentication identity, no realm in the stored key), like some
> ssh key without a password (so once obtained, such ssh key enables a
> malicious user to enter any remote computer the actual user has the
> right to enter).
> Of course the salt/iteration count makes this issue less problematic,
> but it is still a weakness in my opinion.

If salt is not chosen randomly by each system, there is definitely a
risk.  However, this is not how we want things to be deployed, and I
don't think it is how it is being deployed either?  Time will tell.

/Simon