Обсуждение: Re: Automatic upgrade of passwords from md5 to scram-sha256
"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.
regards, tom lane
On Sun, Jan 12, 2025 at 05:59:20PM -0500, Tom Lane wrote: > > 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. Agreed. I think weakening the MD5 handshake to switch to a more secure hash algorithm is unwise. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
On Sun, 12 Jan 2025 at 17:59, Tom Lane <tgl@sss.pgh.pa.us> 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.
It happens upon user login. If the user's password is hashed with an old algorithm, it is re-hashed during login when the Django application running on the Web server has the password sent by the user:
But of course this only works if the old method in use involves sending the password to the server.
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
On Sun, Jan 12, 2025 at 5:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
[snip]
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.
ALTER ROLE xxx WITH PASSWORD accepts hashed values, so a client with the SCRAM-SHA algorithm could:
1. remember the password that was just used to log in,
2. generate the new hash,
3. send that as an ALTER ROLE statement.
Anything which shows up in the logs would be no different than when someone types ALTER ROLE ... WITH PASSWORD from the psql prompt.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
On Mon, Jan 13, 2025 at 3:41 PM Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
On 2025-01-13 12:19:06 -0500, Ron Johnson wrote:
> On Sun, Jan 12, 2025 at 5:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [snip]
>
> 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.
>
>
> ALTER ROLE xxx WITH PASSWORD accepts hashed values, so a client with the
> SCRAM-SHA algorithm could:
> 1. remember the password that was just used to log in,
> 2. generate the new hash,
> 3. send that as an ALTER ROLE statement.
Modifying the client to re-set the password is actually something I
thought about. There are some technical unknowns (e.g. is
PQencryptPasswordConn accessible through ODBC?) and some organisational
difficulties (e.g. can we get the customers to upgrade to the newest
version?), but I guess in our case it would be doable. But in general
changing every to client to upgrade the password doesn't seem feasible.
Unless maybe you are proposing that libpq should do that? That might
work, but it probably also shouldn't do it by default.
That seems to me to be the fastest way to get the feature out to users. (JDBC would also need it.)
Then clients like psql, pgAdmin, etc would need to add those calls.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!