Re: SCRAM minimum PBKDF#2 iteration count

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Alexey Melnikov <alexey.melnikov@xxxxxxxxx> writes:

> Tony Finch wrote:
>
>>On Tue, 10 Mar 2009, Alexey Melnikov wrote:
>>  
>>
>>>Besides, the iteration count can be stored together with user's secret,
>>>so it is really controlled by the server end.
>>>    
>>>
>>However note that a very large proportion of users use multiple clients of
>>varying capability, so per-user isn't fine grained enough.
>>  
>>
> Tony, I don't think doing anything more granular (i.e. per-client)
> would work.
>
> We want to allow servers to store hashed passwords. This means that
> the server end dictates the minimum iteration count.

I don't think we can assume all servers will store hashed passwords.

There are many deployments where passwords are stored in separate
databases.  I would be surprised if all implementations supports stored
hashed passwords.

This means that we will see servers that use a random salt in SCRAM on
every connection.

If we don't want this, the protocol needs to require that servers store
hashed passwords and explain the problem that happens otherwise.  I'm
not sure it is practical to make this a MUST.  Or is there already text
in SCRAM to address this?

/Simon