public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jonathan S. Katz <[email protected]>
To: Andres Freund <[email protected]>
To: Daniel Gustafsson <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Raising the SCRAM iteration count
Date: Mon, 12 Dec 2022 09:47:56 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
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/[email protected]/
Attachments:
[application/pgp-signature] OpenPGP_signature (840B, ../[email protected]/2-OpenPGP_signature)
download
view thread (18+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Raising the SCRAM iteration count
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox