On Fri, Dec 16, 2022 at 4:16 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Laurenz Albe <laurenz.albe@xxxxxxxxxxx> writes:
> On Fri, 2022-12-16 at 17:57 +0530, Daulat wrote:
>> Any idea, how we can set some Password complexities in postgres for user password. Like, we can create profiles in Oracle.
>> I am looking to set the Password complexities (one parameter from each line item has to be complied to):
>> Default password age for users: 90 days.
>> Password first letter will be alphabetic in uppercase.
>> English uppercase characters (A through Z)
>> English lowercase characters (a through z)
>> Base 10 digits (0 through 9)
>> Non-alphabetic characters ~" &_-+='! (){}[):;"'<>,.?/ !@#$%*
>> Password Minimum Length 8 character
> There is no reliable way to do this in PostgreSQL, since the server typically
> never sees the clear text password.
> You should consider using one of the other authentication methods like "ldap"
> and enforce the policy on the LDAP server.
Note that this approach typically leads to a net worsening of security.
Farming out the problem to LDAP means that the password has to be sent
in cleartext not only to the PG server, but then on to the LDAP server
(and in an awful lot of setups, that second hop isn't even done in an
encrypted connection).
There are of course better places to farm out the problem to that don't (necessarily) have this problem. Using GSSAPI for example will never need to send the password in clear, and it's up to the GSSAPI implementation to handle the password complexity rules.
You can fairly easily enforce password age limits in PG using the
ALTER USER ... VALID UNTIL option. But for all this other stuff,
there is no way to enforce it at the server without sending passwords
in cleartext, which reduces security rather than increasing it.
In short: your security guidelines are obsolete and need an update.
The parts about enforcing a certain level of password complexity aren't necessarily obsolete, *if* it is end user passwords and end users change their password directly in the db. This is not a very common scenario, but it can certainly be the case with e.g. analytics people who query the db directly.
The part about requiring repeated password changes is considered actively harmful these days, so it's definitely obsolete. (Note that this is different from the postgres setting for VALID UNTIL which is not about the password being valid until, it's about the entire user being valid until the specified time).
And of course in either case a proper solution like using gssapi/kerberos is the better choice.
