public inbox for [email protected]
help / color / mirror / Atom feedRe: Automatic upgrade of passwords from md5 to scram-sha256
3+ messages / 2 participants
[nested] [flat]
* Re: Automatic upgrade of passwords from md5 to scram-sha256
@ 2025-01-13 17:19 Ron Johnson <[email protected]>
2025-01-13 20:41 ` Re: Automatic upgrade of passwords from md5 to scram-sha256 Peter J. Holzer <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Ron Johnson @ 2025-01-13 17:19 UTC (permalink / raw)
To: pgsql-general
On Sun, Jan 12, 2025 at 5:59 PM Tom Lane <[email protected]> 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!
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Automatic upgrade of passwords from md5 to scram-sha256
2025-01-13 17:19 Re: Automatic upgrade of passwords from md5 to scram-sha256 Ron Johnson <[email protected]>
@ 2025-01-13 20:41 ` Peter J. Holzer <[email protected]>
2025-01-14 01:09 ` Re: Automatic upgrade of passwords from md5 to scram-sha256 Ron Johnson <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Peter J. Holzer @ 2025-01-13 20:41 UTC (permalink / raw)
To: [email protected]
On 2025-01-13 12:19:06 -0500, Ron Johnson wrote:
> On Sun, Jan 12, 2025 at 5:59 PM Tom Lane <[email protected]> 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.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Automatic upgrade of passwords from md5 to scram-sha256
2025-01-13 17:19 Re: Automatic upgrade of passwords from md5 to scram-sha256 Ron Johnson <[email protected]>
2025-01-13 20:41 ` Re: Automatic upgrade of passwords from md5 to scram-sha256 Peter J. Holzer <[email protected]>
@ 2025-01-14 01:09 ` Ron Johnson <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Ron Johnson @ 2025-01-14 01:09 UTC (permalink / raw)
To: [email protected]
On Mon, Jan 13, 2025 at 3:41 PM Peter J. Holzer <[email protected]> wrote:
> On 2025-01-13 12:19:06 -0500, Ron Johnson wrote:
> > On Sun, Jan 12, 2025 at 5:59 PM Tom Lane <[email protected]> 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!
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-01-14 01:09 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-01-13 17:19 Re: Automatic upgrade of passwords from md5 to scram-sha256 Ron Johnson <[email protected]>
2025-01-13 20:41 ` Peter J. Holzer <[email protected]>
2025-01-14 01:09 ` Ron Johnson <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox