> On 24 Sep 2021, at 04:12, Daniel Fone <daniel@fone.net.nz> wrote:
> At the moment, pgcrypto’s `crypt` doesn’t recognise this prefix. However, simply `replace`ing the prefix with $2a$
allowscrypt to validate the hashes. This patch simply adds recognition for the prefix and treats the hash identically
tothe $2a$ hashes.
But 2b and 2a hashes aren't equal, although very similar. 2a should have the
many-buggy to one-correct collision safety and 2b hashes shouldn't. The fact
that your hashes work isn't conclusive evidence.
> Is this a reasonable change to pgcrypto?
I think it's reasonable to support 2b hashes, but not like how this patch does
it.
> I note that the last upstream change brought into crypt-blowfish.c was in 2011, predating this prefix. [5] Are there
deeperconcerns or other upstream changes that need to be addressed alongside this?
Upgrading our crypt_blowfish.c to the upstream 1.3 version would be the correct
fix IMO, but since we have a few local modifications it's not a drop-in. I
don't think it would be too hairy, but one needs to be very careful when
dealing with crypto.
> Is there a better approach to this?
Compile with OpenSSL support, then pgcrypto will use the libcrypto implementation.
> At the moment, the $2x$ variant is supported but not mentioned in the docs, so I haven’t included any documentation
updates.
Actually it is, in table F.16 in the below documentation page we refer to our
supported level as "Blowfish-based, variant 2a".
https://www.postgresql.org/docs/devel/pgcrypto.html
--
Daniel Gustafsson https://vmware.com/