On 10/31/22 6:05 PM, Dagfinn Ilmari Mannsåker wrote:
>> * password (text) - a plaintext password
>> * salt (text) - a base64 encoded salt
> […]
>> + /*
>> + * determine if this a valid base64 encoded string
>> + * TODO: look into refactoring the SCRAM decode code in libpq/auth-scram.c
>> + */
>> + salt_str_dec_len = pg_b64_dec_len(strlen(salt_str_enc));
>> + salt_str_dec = palloc(salt_str_dec_len);
>> + salt_str_dec_len = pg_b64_decode(salt_str_enc, strlen(salt_str_enc),
>> + salt_str_dec, salt_str_dec_len);
>> + if (salt_str_dec_len < 0)
>> + {
>> + ereport(ERROR,
>> + (errcode(ERRCODE_DATA_EXCEPTION),
>> + errmsg("invalid base64 encoded string"),
>> + errhint("Use the \"encode\" function to convert to valid base64 string.")));
>> + }
>
> Instead of going through all these machinations to base64-decode the
> salt and tell the user off if they encoded it wrong, why not accept the
> binary salt directly as a bytea?
If we did that, I think we'd have to offer both. Most users are going to
be manipulating the salt as a base64 string, both because of 1/ how we
store it within the SCRAM secret and 2/ it's convenient in many
languages to work with base64 encoded binary data.
So in that case, we'd still have to go through the "base64 machinations".
However, I'd be OK with allowing for users to specify a "bytea" salt in
addition to a base64 one if that seems reasonable. I would be -1 for
swapping the base64 salt for just a "bytea" one as I think that would
present usability challenges.
Thanks,
Jonathan
