Re: Raising the SCRAM iteration count - Mailing list pgsql-hackers

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/