Hi Daniel,
Thanks for quick reply.
I've found the rapid way to get hash type: htpasswd. Correct me if I am wrong.
#openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021
#htpasswd -nbBC 10 USER PASSWORD
USER:$2y$10$YZNMKHWMye0yY3vvWUK8bOTrJjSRdD.sS2kXythshRkr2l1Qrcfha
So, in my Rocky Linux 8 is $2y$
Now -as you writed- it's clear: hashes are incompatibles.
For me, actually, the better way is to move to aes256 instead of bf, due to openssl bf deprecation. This should make me sleep well for a long time (i hope).
Meanwhile, to solve the case:
- in Linux is quite simple (but insecure), enable legacy ciphers.
- in Windows....uh....i've not found how to solve it because (if i am not wrong) PG 15 is built with openssl 3 internally and i don't known how to enable legacy mode in it.
Actually in Windows (i disagree but my customer wants to use it) the only solution i've found is:
- decrypt data
- backup db
- update PG to a version with openssl 3
- restore db
- re-encrypt data
Many thanks for your clarification, it has been illuminating!
My best regards,
Agharta
Il 15/02/23 14:25, Daniel Gustafsson ha scritto:
On 15 Feb 2023, at 13:15, PG Bug reporting form <noreply@postgresql.org> wrote:
So, the problem seems that the builtin bf cipher implementation cannot
decode the openssl one.
The internal implementation only support $2a$ hashes, are the OpenSSL hashes
$2b$ by any chance? The prefix of the hash includes this version number.
There is a patch floating around for improving blowfish support in pgcrypto but
it hasn't made its way in.
Side note: if I enable legacy mode in openssl3 all works fine and pgcrypto
use the openssl chiper, oblivious.
Can it be solved?
If you relied on Blowfish in OpenSSL 1.1.1 then enabling the legacy provider in
OpenSSL 3.x, or downgrading to OpenSSL 1.1.1 is a solution.
--
Daniel Gustafsson