From: | Christoph Moench-Tegeder <cmt(at)burggraben(dot)net> |
---|---|
To: | Martin Goodson <kaemaril(at)googlemail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Password complexity/history - credcheck? |
Date: | 2024-06-23 10:49:04 |
Message-ID: | Znf9oBPO8dJWHSEi@elch.exwg.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
## Martin Goodson (kaemaril(at)googlemail(dot)com):
> I believe that our security team is getting most of this from our
> auditors, who seem convinced that minimal complexity, password history
> etc are the way to go despite the fact that, as you say, server-side
> password checks can't really be implemented when the database receives
> a hash rather than a clear text password and password minimal
> complexity etc is not perhaps considered the gold standard it once
> was.
The current state of the art is documented (as in, "official", for
arguing with auditors) at
https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
My advice would be to not use secrets stored in the database -
that is, do not use scram-sha-256 - but use an external authentication
system, like Kerberos (might be AD) or LDAP (might also be AD) and have
that managed by the security team: that way all these compliance
topics which they brought up also become their problem :) and a lot
of the processes of recovering and disabling accounts and changing
passords move into a central location, which is most often a good thing[tm].
Or maybe move to client certificates, but if you're managing more
than a few personal accounts rotating certificates might become a
hassle (depending on your user base).
Regards,
Christoph
--
Spare Space
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Goodson | 2024-06-23 13:14:43 | Re: Password complexity/history - credcheck? |
Previous Message | Martin Goodson | 2024-06-23 09:30:17 | Re: Password complexity/history - credcheck? |