BUG #15911: Why no Bcrypt in pg_hba.conf?

"PG" == PG Bug reporting form <noreply@postgresql.org> writes:

PG> I see that the encryption methods supported in
PG> `/etc/postgresql/##/main/pg_hba.conf` are only md5 and sha256.

The supported methods are actually md5 (for historical compatibility)
and SCRAM, which is a better challenge-response protocol than the one we
used to use, using sha256 as the hash algorithm. We do NOT use sha256
as-is as a password hash, SCRAM stores a PBKDF2 result as specified by
the SCRAM protocol definition.

PG> Can you please add `bcrypt` as method option?

Not unless it gets added to the SCRAM specification.

Note that our primary goal here is to provide a secure and standard
challenge-response authentication mechanism, not to provide random
alternate algorithms for password storage.

--
Andrew (irc:RhodiumToad)

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

"PG" == PG Bug reporting form <noreply@postgresql.org> writes:
PG> Can you please add `bcrypt` as method option?

Not unless it gets added to the SCRAM specification.

Note that our primary goal here is to provide a secure and standard
challenge-response authentication mechanism, not to provide random
alternate algorithms for password storage.

Worth noting here is that for us, the price of an additional
authentication mechanism is very high, because it's not just a matter
of adding some code to the server. Client-side libraries also need to
be taught about it, and most of those are not maintained by the core
PG project. So it takes years to make anything happen --- the
addition of SCRAM is still a work in progress, for example.

Thus, we aren't going to add stuff on a whim, and when we do add some
new mechanism, there has to be a really solid argument that it's a
*significant* advance over what we have.

regards, tom lane

It seems that SCRAM is hash-agnostic:
https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism#Protocol_overview

The significant advance is that is well known that SHA algorithms are not
good as Bcrypt for password hashing:

https://rietta.com/blog/bcrypt-not-sha-for-passwords/
https://crypto.stackexchange.com/a/46552
https://security.stackexchange.com/a/133251/27264

Tom Lane wrote:

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

"PG" == PG Bug reporting form <noreply@postgresql.org> writes:
PG> Can you please add `bcrypt` as method option?

Not unless it gets added to the SCRAM specification.

Note that our primary goal here is to provide a secure and standard
challenge-response authentication mechanism, not to provide random
alternate algorithms for password storage.

Worth noting here is that for us, the price of an additional
authentication mechanism is very high, because it's not just a matter
of adding some code to the server. Client-side libraries also need to
be taught about it, and most of those are not maintained by the core
PG project. So it takes years to make anything happen --- the
addition of SCRAM is still a work in progress, for example.

Thus, we aren't going to add stuff on a whim, and when we do add some
new mechanism, there has to be a really solid argument that it's a
*significant* advance over what we have.

regards, tom lane

bcrypt is better than pbkdf2 but pbkdf2 is still good
for the same reasons that bcrypt is good (brute force
resistance). if you want bcrypt/scrypt/argon2, pbkdf2
will probably be good enough. and some organisations
may require pbkdf2 because it is NIST-approved while
the others aren't.

cheers,
raf

"Marco" == Marco Sulla <github@marco.sulla.e4ward.com> writes:

Marco> It seems that SCRAM is hash-agnostic:
Marco> https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism#Protocol_overview

Regardless, SHA256 is the algorithm specified in the current standard
(see RFC 7677), and since the client and server need to agree on this,
we have very strong reasons (as Tom pointed out) not to proliferate
algorithms.

Marco> The significant advance is that is well known that SHA
Marco> algorithms are not good as Bcrypt for password hashing:

Marco> https://rietta.com/blog/bcrypt-not-sha-for-passwords/

This is comparing bcrypt against _one round_ of SHAx, which is not what
SCRAM uses (it uses PBKDF2).

Marco> https://crypto.stackexchange.com/a/46552

This starts out by comparing bcrypt with (unsalted!) SHA-512, but then
does at least go on to mention PBKDF2.

Marco> https://security.stackexchange.com/a/133251/27264

This at least looks like it's comparing the right things.

--
Andrew (irc:RhodiumToad)

On Wed, Jul 17, 2019 at 09:22:42AM +1000, raf wrote:

Tom Lane wrote:

Thus, we aren't going to add stuff on a whim, and when we do add some
new mechanism, there has to be a really solid argument that it's a
*significant* advance over what we have.

Agreed. Adding a new authentication method is a lot of work as this
extends the protocol, and still with SCRAM we are not done yet with
drivers not linked directly with libpq, and I have some experience in
the area.

bcrypt is better than pbkdf2 but pbkdf2 is still good
for the same reasons that bcrypt is good (brute force
resistance). if you want bcrypt/scrypt/argon2, pbkdf2
will probably be good enough. and some organisations
may require pbkdf2 because it is NIST-approved while
the others aren't.

Good, we use PBKDF2 for the password salting. If it is possible to
justify that this has much more benefits in the current practices, and
that we are still able to stick with the latest RFC specifications,
there may be an argument to get something done and improved, but I
don't quite see what that would be and more importantly if we actually
need to do so.
--
Michael