On Thu, Jan 20, 2011 at 3:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniel Farina <drfarina@acm.org> writes:
>> I wanted to test the waters on how receptive people might be to an
>> extension that would allow Postgres to support two passwords for a
>> given role.
>
> Not very. Why don't you just put two roles in the same group?
How does this work with newly created objects? Is there a way to have
them default objects to a different owner, the parent of the two
roles?
It is highly desirable that no ALTER <OBJECT> statements should need
issuing after the password transition is complete. As-is, though, I
don't understand how that would be possible.
It would also be nice to be able to change a password without changing
the role name. In the case of password rotation, the goal would be to
drop the old password after all clients have had reasonable chance to
get an update. One could work around by generating new
username+password pairs constantly, but there are conveniences to
having a stable public-identifier for a role in addition to a private
secret used to authenticate it (or, as is the case with this proposal,
more than one acceptable private secrets). Changing the username all
the time to facilitiate this basically renders it part of a unstable,
two-part secret key, and the job of having a stable, public identifier
is pushed up the application stack.
--
fdr