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

From Jeff Davis
Subject Re: [PoC/RFC] Multiple passwords, interval expirations
Date
Msg-id ee929543114d08340554ac075a27f44dbc7ee431.camel@j-davis.com
Whole thread Raw
In response to Re: [PoC/RFC] Multiple passwords, interval expirations  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: [PoC/RFC] Multiple passwords, interval expirations
Re: [PoC/RFC] Multiple passwords, interval expirations
List pgsql-hackers
On Fri, 2023-10-06 at 14:26 -0500, Nathan Bossart wrote:
> I guess it's more of the latter.  Perhaps one potential use case
> would be
> short-lived credentials that are created on demand.  Such a password
> might
> only be valid for something like 15 minutes, and many users might
> have the
> ability to request a password for the database role.  I don't know
> whether
> there is a ton of demand for such a use case, and it might already be
> solvable by just creating separate roles.  In any case, if there's
> general
> agreement that we only want to target the rotation use case, that's
> fine by
> me.

The basic problem, as I see it, is: how do we keep users from
accidentally dropping the wrong password? Generated unique names or
numbers don't solve that problem. Auto-incrementing or a created-at
timestamp solves it in the sense that you can at least look at a system
view and see if there's a newer one, but it's a little awkward. A
validity period is a good fit if all passwords have a validity period
and we don't change it, but gets awkward otherwise.

I'm also worried about two kinds of clutter:

* old passwords not being garbage-collected
* the identifier of the current password always changing (perhaps fine
if it'a a "created at" ID?)

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Restoring default privileges on objects
Next
From: Laurenz Albe
Date:
Subject: Re: Restoring default privileges on objects