From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "M, Anbazhagan" <Anbazhagan(dot)M(at)netapp(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Reg: Alternate way of hashing database role passwords |
Date: | 2024-06-26 16:11:45 |
Message-ID: | 1516396.1719418305@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"M, Anbazhagan" <Anbazhagan(dot)M(at)netapp(dot)com> 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 accepted as a algorithms that should be used for encrypting or hashing the password at storage as per the Organization's Cryptography Standard.
> If it is not in current plan, is there a plan to include that in subsequent versions?
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 repeat that. Moreover, I know of
no reason to think that SHA-256 isn't perfectly adequate.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-06-26 16:28:23 | Re: libpq: Fix lots of discrepancies in PQtrace |
Previous Message | Laurenz Albe | 2024-06-26 15:53:02 | Re: Wrong security context for deferred triggers? |