On Wed, Dec 12, 2018 at 07:30:18AM -0700, Bear Giles wrote:
> BTW another solution is SSO, e.g., Kerberos. I still need to submit a patch to
> pgsql to handle it better(*) but with postgresql itself you sign into the
> system and then the database server will just know who you are. You don't have
>
On Tue, Dec 11, 2018 at 09:56:54AM -0500, Tom Lane wrote:
> Michael Banck writes:
> > The same was requested in https://dba.stackexchange.com/questions/91252/
> > how-to-know-when-postgresql-password-is-changed so I was wondering
> > whether this would be a welcome change/addition, or whether peop
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > ... Definitely a +1 from me, but I'd like us to be thinking about the other
> > things we should be doing in this area to bring our password-based
> > authentication mechanism kicking-and-screaming into the current deca
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> This has all the same practical problems as recording object creation
>> times, which we're not going to do either. (You can consult the
>> archives for details, but from memory, the stickiest aspects revolve
>> around what to do d
Stephen Frost writes:
> ... Definitely a +1 from me, but I'd like us to be thinking about the other
> things we should be doing in this area to bring our password-based
> authentication mechanism kicking-and-screaming into the current decade.
I'm not really excited about reinventing the whole of
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Banck writes:
> > The same was requested in https://dba.stackexchange.com/questions/91252/
> > how-to-know-when-postgresql-password-is-changed so I was wondering
> > whether this would be a welcome change/addition, or whether people thin
Greetings,
* Michael Banck (michael.ba...@credativ.de) wrote:
> a customer recently mentioned that they'd like to be able to see when a
> (md5, scram) role had their password last changed.
There is an awful lot here that we really should be doing. For a long
time, that felt prettty stalled beca
Could you add your own UPDATE trigger to the password table? It can write
an entry to a new table, e.g., (userid, current date) whenever a record in
that table is modified.
On an earlier question - the issue isn't whether someone can crack your
password, it's possible disclosure in archive media s
On 12/11/18 9:56 AM, Tom Lane wrote:
> I've heard that if you want to implement a password aging policy, PAM
> authentication can manage that for you; but I don't know the details.
Interesting idea ... could use pam-pgsql[1] and PAM as the
authentication method. Might result in another connection
Michael Banck writes:
> The same was requested in https://dba.stackexchange.com/questions/91252/
> how-to-know-when-postgresql-password-is-changed so I was wondering
> whether this would be a welcome change/addition, or whether people think
> it's not worth bothering to implement it?
This has all
Hi,
Am Dienstag, den 11.12.2018, 23:45 +1300 schrieb Gavin Flower:
> On 11/12/2018 23:33, Michael Banck wrote:
> > a customer recently mentioned that they'd like to be able to see when a
> > (md5, scram) role had their password last changed.
> >
> > Use-cases for this would be issueing an initial
On 11/12/2018 23:33, Michael Banck wrote:
Hello,
a customer recently mentioned that they'd like to be able to see when a
(md5, scram) role had their password last changed.
Use-cases for this would be issueing an initial password and then later
making sure it got changed, or auditing that all pa
12 matches
Mail list logo
