On Thu, Nov 10, 2022 at 11:14:34PM -0500, Jonathan S. Katz wrote:
> On 10/31/22 8:56 PM, Michael Paquier wrote:
>> Well, one could pass a salt based on something generated by random()
>> to emulate what we currently do in the default case, as well. The
>> salt length is an extra possibility, letting it be randomly generated
>> by pg_strong_random().
>
> Sure, this is a good point. From a SQL level we can get that from pgcrypto
> "gen_random_bytes".
Could it be something we could just push into core? FWIW, I've used
that quite a bit in the last to cheaply build long random strings of
data for other things. Without pgcrypto, random() with
generate_series() has always been kind of.. fun.
+SELECT scram_build_secret_sha256(NULL);
+ERROR: password must not be null
+SELECT scram_build_secret_sha256(NULL, NULL);
+ERROR: password must not be null
+SELECT scram_build_secret_sha256(NULL, NULL, NULL);
+ERROR: password must not be null
This is just testing three times the same thing as per the defaults.
I would cut the second and third cases.
git diff --check reports some whitespaces.
scram_build_secret_sha256_internal() is missing SASLprep on the
password string. Perhaps the best thing to do here is just to extend
pg_be_scram_build_secret() with more arguments so as callers can
optionally pass down a custom salt with its length, leaving the
responsibility to pg_be_scram_build_secret() to create a random salt
if nothing has been given?
--
Michael