[jdev] plaintext passwords hack

[Simon Josefsson]

Kurt Zeilenga <Kurt.Zeilenga at Isode.com> writes:

> On Dec 17, 2009, at 7:58 AM, Simon Josefsson wrote:
>
>> Tomasz Sterna <tomek at xiaoka.com> writes:
>> 
>>> Dnia 2009-12-17, czw o godzinie 14:35 +0100, Simon Josefsson pisze:
>>>> If you don't store the hashed password for SCRAM, you need to burn CPU
>>>> time for every login to derive the SCRAM hash keys.  That doesn't scale
>>>> well.
>>> 
>>> Why do you say so?
>>> 
>>> It scales well vertically by CPU upgrade, and horizontally by putting
>>> more machines/CPUs to handle user connections.
>> 
>> Sure, but caching the hashed values scales better.  Remember, we are not
>> talking about just one hash call, typically there is 4096 hash
>> iterations when deriving the keys from a password in SCRAM.
>> 
>> If you do want to hash the password on every authentication with SCRAM,
>> make sure you use the same salt and iteration count every time,
>> otherwise clients cannot cache ClientKey&ServerKey (or SaltedPassword)
>> which will cause performance problems for mobile devices...
>> 
>> ...unless you use a very low iteration count value (e.g., 1).  Is that
>> what you are suggesting?
>
> I find it interesting that large iteration counts are more a determent
> to the intended clients and servers of the system than a sophisticated
> attacker.  That is, where a client and server have quite limited
> resources, an attacker has to viewed has a massive resources available
> to their disposal (at very little cost to attacker).

Yes, and I suspect we'll see some SCRAM deployments with iteration count
1 for this reason.

An iteration count of 1 isn't too problematic, but I fear poor user
experience in clients if servers were to use a new salt every time.
Some clients may re-query the user for the password when that happens.

Low iteration counts removes one nice features of SCRAM (mitigating
dictionary attacks on stolen hash databases).  It is possible to get the
features back, without the high iteration cost, by using SRP though.
(But obviously SRP has other pros and cons..)

/Simon