Re: [PoC/RFC] Multiple passwords, interval expirations - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [PoC/RFC] Multiple passwords, interval expirations
Date
Msg-id ZTJz+CQZeQMKV7VM@tamriel.snowman.net
Whole thread Raw
In response to Re: [PoC/RFC] Multiple passwords, interval expirations  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Greetings,

* Jeff Davis (pgsql@j-davis.com) wrote:
> 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.

Sure, no objection to adding that and seems like it should be fairly
easy ... but then again, I tend to feel that we should do that for all
of the objects in the system and we've got some strong feelings against
doing that from others.  Perhaps this case is different to them, in
which case, great, but if it's not, it'd be unfortunate for this feature
to get bogged down due to that.

> > > (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.

Sure, no worries.

> 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?

Short answer, yes ... but seems that wasn't actually done yet.  Requires
a bit of additional work, since the client needs to get the existing
salt (note that as part of the SCRAM typical exchange, the client is
provided with the salt, so this isn't exposing anything new) to use to
construct what is then sent to the server to store.  We'll also need to
decide how to handle the case if the client tries to send a password
that doesn't have the same salt as the existing ones (regardless of how
many passwords we end up supporting).  Perhaps we require the user,
through the grammar, to make clear if they want to add a password, and
then error if they don't provide a matching salt, or if they want to
remove existing passwords and replace with the new one.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: A performance issue with Memoize
Next
From: Stephen Frost
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.