Greetings, * Tom Lane (tgl@xxxxxxxxxxxxx) wrote: > Dave Hughes <dhughes20@xxxxxxxxx> writes: > > I have a requirement to set some password complexity for our database such > > as length of password, upper case, lower case, special characters, > > expiration limit, reuse, etc. > > Usually, if you have to do something like that, we recommend setting PG to > use PAM authentication and configuring the restrictions on the PAM side. Trying to do this with PAM really isn't reasonable in my experience, and I've been there and have gone through the foolishness required to make it work (in a couple different ways). PG doesn't run as root though and many PAM modules expect that, so you end up having to deal with something like pam_sasl and saslauthd, which is a pain. I really don't think it's reasonable for us to be recommending this, and it doesn't work if what you actually want is for PG to be storing the passwords (without something like pam_pgsql, but that requires things like the password being passed to PG in cleartext on every authentication, and is awkward to set up...). Basically, you can hack things up enough to get the password complexity requirement, kind of (note that you can't use \password with psql, for example, or any other client-side password change mechanism through PG, so you have to force password changes to be done during authentication, which is bizarre- users can't change their own password whenever they wish but rather only when PAM forces them to), but you then end up running a system that has passwords in the clear being sent to PG by the client, which is certainly no good. > The only native capability in that direction is that you can set a > password expiration date. Right, which is unfortunate- we should have a better solution. > Note that it's widely believed that this sort of thing makes you LESS > secure, not more. Quite aside from the well-established fact that forced > password changes are bad from a human-factors standpoint, you can't check > any of those other points unless the password is sent to the server as > cleartext. That creates its own set of vulnerabilities, and I don't > know of anybody who considers it good practice. Having the password sent to the server during a PW change isn't great, certainly, but it's far worse to have the password sent in the clear to the server on every authentication, which is what using something like PAM ends up doing. > > I saw there was a module you can use for this called passwordcheck. Seems > > easy to install, but I don't see how you can configure it for you specific > > needs? > > passwordcheck hasn't got any out-of-the-box configurability. It's mainly > meant as sample code that people could modify if they have a mind to. I believe some people actually do use it, as it can be compiled with cracklib, which can be configured. > (I seem to recall some recent discussion about deprecating/removing > passwordcheck altogether, but I can't find it right now.) +1 for my part to dropping it, and replacing it with a proper built-in capability here, that would work with our SCRAM-based auth. Thanks, Stephen
Attachment:
signature.asc
Description: PGP signature
