Reg: Alternate way of hashing database role passwords
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 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?
Thanks and Regards,
Anbazhagan M
"M, Anbazhagan" <Anbazhagan.M@netapp.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
On Wed, Jun 26, 2024 at 12:11 PM Tom Lane <tgl@sss.pgh.pa.us> 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 repeat that. Moreover, I know of
no reason to think that SHA-256 isn't perfectly adequate.
If history is any guide, every algorithm will eventually look too
weak. It seems inevitable that we're going to have to keep changing
algorithms as time passes. 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.
What I find a bit surprising about Anbazhagan's question is that he
asks about PBKDF2, which seems to be part of SCRAM already.[1]https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism#Password-based_derived_key,_or_salted_password In
fact, I think all the things he lists are key derivation functions,
not hash functions. I'm far from a cryptography expert, but it seems
surprising to me that somebody would be concerned about the KDF rather
than the hash function. We know that people get concerned about code
that still uses MD5, for example, or SHA-1, but this is the first time
I can remember someone expressing a concern about a KDF.
Anbazhagan, or anyone, is there some reason to think that the PBKDF2
approach used by SCRAM is a problem?
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Jun 26, 2024 at 12:11 PM Tom Lane <tgl@sss.pgh.pa.us> 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 repeat that. Moreover, I know of
no reason to think that SHA-256 isn't perfectly adequate.
If history is any guide, every algorithm will eventually look too
weak. It seems inevitable that we're going to have to keep changing
algorithms as time passes. 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.
Totally agreed, that day will come. What I'm pushing back on is the
suggestion that we should implement a ton of variant password hash
functionality on the basis of somebody's whim. The costs are large
and they are not all paid by us, so the bar to replacing any part
of that has to be very high.
What I find a bit surprising about Anbazhagan's question is that he
asks about PBKDF2, which seems to be part of SCRAM already.[1] In
fact, I think all the things he lists are key derivation functions,
not hash functions.
This I don't have any info about.
regards, tom lane
On 26 Jun 2024, at 18:59, Robert Haas <robertmhaas@gmail.com> 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.
Correct, SCRAM is an authentication method which can use different hashing
algorithms. There are current drafts for SCRAM-SHA-512 and SHA3-512 but they
are some way away from being standardized. If they become standards at some
point reasonable to extend our support, but until then there is no evidence
that what we have is insecure AFAIK.
https://datatracker.ietf.org/doc/html/draft-melnikov-scram-sha-512
https://datatracker.ietf.org/doc/html/draft-melnikov-scram-sha3-512
What I find a bit surprising about Anbazhagan's question is that he
asks about PBKDF2, which seems to be part of SCRAM already.
In scram_SaltedPassword() we perform PBKDF2 with HMAC as the pseudorandom
function.
--
Daniel Gustafsson