Re: Raising the SCRAM iteration count

[Jonathan S. Katz]

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.

==snip==

==snip==



However, I do like the idea of a GUC.

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: 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.¶ 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.

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.

Thanks,

Jonathan

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

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.

OpenPGP_signature
Description: OpenPGP digital signature