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

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.

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.

PGPASSWORD=passme pgbench -n -C -f ~/tmp/select.sql -h 127.0.0.1 -T10 -U passme

md5: tps = 158.577609
scram: tps = 38.196362

Greetings,

Andres Freund