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 ZTAodpyP/C7yCQcM@tamriel.snowman.net
Whole thread Raw
In response to Re: [PoC/RFC] Multiple passwords, interval expirations  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: [PoC/RFC] Multiple passwords, interval expirations
List pgsql-hackers
Greetings,

* Jeff Davis (pgsql@j-davis.com) wrote:
> On Tue, 2023-10-17 at 22:52 -0400, Stephen Frost wrote:
>
> > Reading back through the thread, from a user perspective, the primary
> > one seems to be that passwords are expected to be named.  I'm
> > surprised
> > this is being brought up as such a serious concern.  Lots and lots
> > and
> > lots of things in the system require naming, after all, and the idea
> > that this is somehow harder or more of an issue is quite odd to me.
>
> In the simplest intended use case, the names will be arbitrary and
> temporary. It's easy for me to imagine someone wondering "was I
> supposed to delete 'bear' or 'lion'?". For indexes and other objects,
> there's a lot more to go on, easily visible with \d.

Sure, agreed.

> Now, obviously that is not the end of the world, and the user could
> prevent that problem a number of different ways. And we can do things
> like improve the monitoring of password use, and store the password
> creation time, to help users if they are confused. So I don't raise
> concerns about naming as an objection to the feature overall, but
> rather a concern that we aren't getting it quite right.

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?

> Maybe a name should be entirely optional, more like a comment, and the
> passwords can be referenced by the salt? The salt needs to be unique
> for a given user anyway.

I proposed an approach in the email you replied to explicitly suggesting
a way we could make the name be optional, so, sure, I'm generally on
board with that idea.  Note that it'd be optional for the user to
provide and then we'd simply generate one for them and then that name is
what would be used to refer to that password later.

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

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Devrim Gündüz
Date:
Subject: Re: LLVM 16 (opaque pointers)
Next
From: Alexander Korotkov
Date:
Subject: Re: Removing unneeded self joins