* DM (dm.aeqa@gmail.com) wrote:
> How to force postgres users to follow password standards and renewal
> policies?
It's not trivial, sadly. Regarding renewal, you can use the 'valid
until' role parameter to implement a "only good until" mechanism, and
then update that using a security definer function when the password is
changed. You would then have to have your application calling that
function for password changes.
Another approach, which I've used in the past but I truely dislike, is
to use PAM, cracklib, pam_tally, etc. The problem with this is that if
you use pam_unix as the basic "password storage" mechanism, you have to
jump through lots of nasty hoops and configure things in a really ugly
way. You *could* use another PAM module besides pam_unix in the stack,
but I'm not sure what the best suggestion there would be, and I think
you'd still have ugly permission problems with pam_tally..
All-in-all, there really isn't a very good solution here, if you're
forced to use the PG system for your authentication. If you can move
*away* from that (something I would definitely encourage), it becomes
alot more reasonable- eg: use Kerberos for your authentication and
implement the password standards, renewal policies, etc, there. Or, use
ident auth under Unix with unix domain sockets and make sure you
configure the system-wide PAM requirements according to your policies.
Both of those approaches avoid putting PWs in PG, which gives you a way
to deal with the fact that PG doesn't have support for these kinds of
policies.
There have been a number of discussions about this issue but, sadly, I
don't know that anyone has come up with a good solution yet. I've been
sorely tempted to rewrite pam_unix to support an alternative storage
location for the files it needs (along with pam_tally, etc), so that you
could then use PAM under PG w/ just a "pg/etc" directory that had the
PG-used pam_unix files (passwd, shadow, etc) instead of the system-wide
ones.
Thanks,
Stephen