Re: [PoC/RFC] Multiple passwords, interval expirations

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Gurjeet Singh <gurjeet@singh.im>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Brindle, Joshua" <joshuqbr@amazon.com>, Jacob Champion <jchampion@timescale.com>
Date: 2023-10-20T02:22:07Z
Lists: pgsql-hackers
On Wed, 2023-10-18 at 14:48 -0400, Stephen Frost wrote:
> Right, we need more observability, agreed, but that's not strictly
> necessary of this patch and could certainly be added independently. 
> Is
> there really a need to make this observability a requirement of this
> particular change?

I won't draw a line in the sand, but it feels like something should be
there to help the user keep track of which password they might want to
keep. At least a "created on" date or something.

> > (Aside: is the uniqueness of the salt enforced in the current
> > patch?)
> 
> Err, the salt has to be *identical* for each password of a given
> user,
> not unique, so I'm a bit confused here.

Sorry, my mistake.

If the client needs to use the same salt as existing passwords, can you
still use PQencryptPasswordConn() on the client to avoid sending the
plaintext password to the server?

Regards,
	Jeff Davis




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. MergeAttributes: convert pg_attribute back to ColumnDef before comparing