I'm administering a PotsgreSQL server and recently I realized that my "nonsuperuser" users have the possibility to change the secure passwords that I assign them for insecure ones.

I searched in the REVOKE docs, but I couldn't find a way to prevent that. It is possible?

Thanks in advance!

  • 4
    Do you actually want to prevent them from changing their passwords, or do you want to prevent them from setting a new password unless it's reasonably secure? – RDFozz Jun 13 '17 at 19:19

AFAIK, there is no way to prevent a user from changing his/her password. It's been discussed (quite long ago) on ocassion on PostgreSQL mailing list, and all the answers I remember were basically "no, you can't".

However, there's a contrib module, called passwordcheck, whose objective is to guarantee the strength of passwords, if that's what you wish (as already commented by @RDFozz).

From the docs:

The passwordcheck module checks users' passwords whenever they are set with CREATE ROLE or ALTER ROLE. If a password is considered too weak, it will be rejected and the command will terminate with an error.

To enable this module, add '$libdir/passwordcheck' to shared_preload_libraries in postgresql.conf, then restart the server.

I've never used the module myself.

  • 4
    Cool answer didn't know about passwordcheck. – Evan Carroll Jun 13 '17 at 20:50
  • 1
    You could use the same hook that passwordcheck uses to reject password changes though, I expect. You'd have to write a C extension. – Craig Ringer Jun 14 '17 at 2:58
  • 1
    @CraigRinger: I assume you could just modify passwordcheck or configure it in such a way that it refuses any password change (let's say, conceptually, that you require all new passwords to be 1.000 chars in length, made of different ASCII characters). However, this would "freeze" whichever roles were already defined, and allow no changes or additions at all... Probably a dangerous scenario. – joanolo Jun 14 '17 at 6:43
  • 1
    @joanolo: noting passwordcheck's reservations about its own security (it primarily validates passwords sent unencrypted on the network, which is a separate risk unless the network itself is encrypted), and also that rewriting passwordcheck could be a major task - hypothetically, if passwordcheck enforces that say the first 4 characters of the password represent a cryptographic checksum of the rest of the password, then ericgcc could generate and set a password but a user would not be able to set a password that would satisfy the test. But the passwords would be even longer than necessary. – Robert Carnegie Jun 14 '17 at 10:04
  • 1
    Afterthought: to prevent password re-use (which I overlooked), you could issue checksigned passwords, then change the salt of the checksign formula so that setting that password again isn't possible. This will defeat users who decide it is easier to set every user's password to be the same... until you have to give another one out. That's if Postgresql or passwordcheck don't prevent re-using passwords anyway (preventing re-using a password that a different user used is dubious though). – Robert Carnegie Jun 14 '17 at 10:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.