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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [PoC/RFC] Multiple passwords, interval expirations
Дата
Msg-id ZTAodpyP/C7yCQcM@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [PoC/RFC] Multiple passwords, interval expirations  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: [PoC/RFC] Multiple passwords, interval expirations
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Devrim Gündüz
Дата:
Сообщение: Re: LLVM 16 (opaque pointers)
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Removing unneeded self joins