Обсуждение: BUG #15911: Why no Bcrypt in pg_hba.conf?
The following bug has been logged on the website: Bug reference: 15911 Logged by: Marco Sulla Email address: github@marco.sulla.e4ward.com PostgreSQL version: 11.4 Operating system: Lubuntu 18.04 Description: I see that the encryption methods supported in `/etc/postgresql/##/main/pg_hba.conf` are only md5 and sha256. It's proved that Bcrypt is a better algorithm for encrypting passwords, even than sha512. Spring Boot, for example, uses Bcrypt by default. Can you please add `bcrypt` as method option?
>>>>> "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:
The significant advance is that is well known that SHA algorithms are not good as Bcrypt for password hashing:
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