Nicolas Williams wrote:
On Wed, Sep 23, 2009 at 08:22:25PM -0500, Ben Campbell wrote:
-- 2nd paragraph: " ...increase the iteration count over time."
Can you elaborate on how this helps, and possibly offer guidance on
how implementations should use it?
Good point. With SCRAM as specified, a server cannot increase the
iteration count without somehow getting access to the cleartext
password. If the server were to store SaltedPassword _and_
U_iteration_count (from Hi()'s internals), then the server could compute
a new SaltedPassword and U_iteration_count with a higher iteration
count. However, the server isn't intended to store SaltedPassword,
rather, the server stores StoredKey and ServerKey, and there's a reason
for this: a server that's never authenticated a given user before cannot
impersonate that user, but if the server were to store SaltedPassword,
then the server could impersonate the user.
Thus, to "increase the iteration count over time" requires, effectively,
changing the user's password. This is probably worth pointing out.
I tried to clarify that.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf