> On 26 Jun 2024, at 18:59, Robert Haas wrote:
> However, it seems like SCRAM is designed so
> that different hash functions can be substituted into it, so what I'm
> hoping is that we can keep SCRAM and just replace SCRAM-SHA-256 with
> SCRAM-WHATEVER when SHA-256 starts to look too weak.
Corre
Robert Haas writes:
> On Wed, Jun 26, 2024 at 12:11 PM Tom Lane wrote:
>> It is not, and I doubt we have any interest in dramatically expanding
>> the set of allowed password hashes. Adding SCRAM was enough work and
>> created a lot of client-v-server and cross-version incompatibility
>> already
On Wed, Jun 26, 2024 at 12:11 PM Tom Lane wrote:
> It is not, and I doubt we have any interest in dramatically expanding
> the set of allowed password hashes. Adding SCRAM was enough work and
> created a lot of client-v-server and cross-version incompatibility
> already; nobody is in a hurry to r
"M, Anbazhagan" writes:
> Currently we are using SHA-256 default for password_encryption in our
> postgresql deployments. Is there any active work being done for adding
> additional hashing options like PBKDF2, HKDF, SCRYPT or Argon2 password
> hashing functions, either of which is only accepte
Hi Team,
Currently we are using SHA-256 default for password_encryption in our
postgresql deployments. Is there any active work being done for adding
additional hashing options like PBKDF2, HKDF, SCRYPT or Argon2 password hashing
functions, either of which is only accepted as a algorithms that
