Re: Raising the SCRAM iteration count

On 12/9/22 7:15 PM, Andres Freund wrote:
> Hi,
>
> On 2022-12-09 11:55:07 +0100, Daniel Gustafsson wrote:
>> 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.

To throw on a bit of paint, if we do change it, we should likely follow
what would come out in a RFC.

While the SCRAM-SHA-512 RFC is still in draft[1], the latest draft it
contains a "SHOULD" recommendation of 10000, which was bumped up from
4096 in an earlier version of the draft:

==snip==
Therefore, the recommendation of this specification is that the hash
iteration- count SHOULD be at least 10000, but careful consideration
ought to be given to using a significantly higher value, particularly
where mobile use is less important.¶
==snip==

I'm currently ambivalent (+0) on changing the default. I think giving
the user more control over iterations ([2], and follow up work to make
it easier to set iteration account via client) can help with this.

However, I do like the idea of a GUC.

> I am extremely doubtful it's a good idea to increase the default (if anything
> the opposite). 0.1 seconds is many times the connection establishment
> overhead, even over network. I've seen users complain about postgres
> connection establishment overhead being high, and it just turned out to be due
> to scram - yes, they ended up switching to md5, because that was the only
> viable alternative.

Ugh, I'd be curious to know how often that is the case. That said, I
think some of the above work could help with that.

Thanks,

Jonathan

[1] https://datatracker.ietf.org/doc/html/draft-melnikov-scram-sha-512
[2] https://postgr.es/m/fce7228e-d0d6-64a1-3dcb-bba85c2fac85@postgresql.org/