Re: Raising the SCRAM iteration count

On 09/12/2022 12:55, Daniel Gustafsson wrote:
> In the thread about user space SCRAM functions [0] I mentioned that it might be
> wise to consider raising our SCRAM iteration count. The iteration count is an
> important defence against brute-force attacks.
>
> Our current hardcoded value for iteration count is 4096, which is based on a
> recommendation from RFC 7677. This is however the lower end of the scale, and
> is related to computing power in 2015 generation handheld devices. The
> relevant paragraph in section 4 of RFC 7677 [1] reads:
>
> "As a rule of thumb, the hash iteration-count should be such that a modern
> machine will take 0.1 seconds to perform the complete algorithm; however,
> this is unlikely to be practical on mobile devices and other relatively low-
> performance systems. At the time this was written, the rule of thumb gives
> around 15,000 iterations required; however, a hash iteration- count of 4096
> takes around 0.5 seconds on current mobile handsets."
>
> It goes on to say:
>
> "..the recommendation of this specification is that the hash iteration- count
> SHOULD be at least 4096, but careful consideration ought to be given to
> using a significantly higher value, particularly where mobile use is less
> important."
>
> Selecting 4096 was thus a conservative take already in 2015, and is now very
> much so. On my 2020-vintage Macbook I need ~200k iterations to consume 0.1
> seconds (in a build with assertions). Calculating tens of thousands of hashes
> per second on a consumer laptop at a 4096 iteration count is no stretch. A
> brief look shows that MongoDB has a minimum of 5000 with a default of 15000
> [2]; Kafka has a minimum of 4096 [3].
>
> Making the iteration count a configurable setting would allow installations to
> raise the iteration count to strengthen against brute force attacks, while
> still supporting those with lower end clients who prefer the trade-off of
> shorter authentication times.
>
> The attached introduces a scram_iteration_count GUC with a default of 15000
> (still conservative, from RFC7677) and a minimum of 4096. Since the iterations
> are stored per secret it can be altered with backwards compatibility.

We just had a discussion with a colleague about using a *smaller*
iteration count. Why? To make the connection startup faster. We're
experimenting with a client that runs in a Cloudflare worker, which is a
wasm runtime with very small limits on how much CPU time you're allowed
to use (without paying extra). And we know that the password is randomly
generated and long enough. If I understand correctly, the point of
iterations is to slow down brute-force or dictionary attacks, but if the
password is strong enough to begin with, those attacks are not possible
regardless of iteration count. So I would actually like to set the
minimum iteration count all the way down to 1.

- Heikki