Raising the SCRAM iteration count

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.

Clientside the count is still at 4096 to limit the scope of this patch a bit.
For psql it would mean adding options to \password which should be a thread of
its own. For libpq one can imagine specifying this in the algorithm parameter
passed to PQencryptPasswordConn like "scram-sha-256:100000" or something
similar. It's premature to pursue those without agreement that we should make
the count configurable though. If this patch is accepted, I'll work on that
next.

Thoughts?

--
Daniel Gustafsson https://vmware.com/

[0] fce7228e-d0d6-64a1-3dcb-bba85c2fac85(at)postgresql(dot)org
[1] https://www.rfc-editor.org/rfc/rfc7677#section-4
[2] https://www.mongodb.com/docs/manual/reference/parameters/#mongodb-parameter-param.scramSHA256IterationCount
[3] https://docs.confluent.io/platform/current/kafka/authentication_sasl/authentication_sasl_scram.html#security-considerations-for-sasl-scram