* DM (dm.aeqa@xxxxxxxxx) 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
Attachment:
signature.asc
Description: Digital signature
