Re: User functions for building SCRAM secrets
От | Michael Paquier |
---|---|
Тема | Re: User functions for building SCRAM secrets |
Дата | |
Msg-id | Y3WmBihb0Jkhqf42@paquier.xyz обсуждение исходный текст |
Ответ на | Re: User functions for building SCRAM secrets ("Jonathan S. Katz" <jkatz@postgresql.org>) |
Ответы |
Re: User functions for building SCRAM secrets
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: