On 1/12/25 17:59, Tom Lane wrote:
> "Peter J. Holzer" <hjp-pgsql@hjp.at> writes:
>> The web framework Django will automatically and transparently rehash any
>> password with the currently preferred algorithm if it isn't stored that
>> way already.
>
> Really? That implies that the framework has access to the original
> cleartext password, which is a security fail already.
>
>> Can PostgreSQL do that, too? (I haven't found anything)
>
> No. The server has only the hashed password, it can't reconstruct
> the original.
>
>> If the password for the user is stored as an MD5 hash, the server
>> replies to the startup message with an AuthenticationCleartextPassword
>> respnse to force the client to send the password in the clear
>> (obviously you only want to do that if the connection is TLS-encrypted
>> or otherwise safe from eavesdropping).
>
> I think this idea is a nonstarter, TLS or not. We're generally moving
> in the direction of never letting the server see cleartext passwords.
> It's already possible to configure libpq to refuse such requests
> (see require_auth parameter), although that hasn't been made the
> default.
<hand-wavy-thought>
Given PQchangePassword[1] in pg17, I wonder if the next step could be to
have libpq somehow know/detect that an algorithm change is needed and
execute that (or some equivalent) from the client side? And presumably
we could ask pgjdbc to implement something similar.
</hand-wavy-thought>
Joe
[1]
https://www.postgresql.org/docs/17/libpq-misc.html#LIBPQ-PQCHANGEPASSWORD
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
