I wrote:
> A server-side plugin can provide a guarantee that there are no bad
> passwords (for some value of bad, and with some possible adverse
> consequences). We don't have that today.
BTW, it strikes me that ALTER USER RENAME introduces an interesting
hazard for such a plugin. Consider
CREATE USER joe;
ALTER USER joe PASSWORD joe; -- presumably, plugin will reject this
ALTER USER joe PASSWORD mumblefrotz; -- assume this is considered OK
ALTER USER joe RENAME TO mumblefrotz;
Now we have a user with name equal to password, which no sane security
policy will think is a good thing, but the plugin had no chance to
prevent it.
In the case where the password is stored MD5-crypted, we clear it on
RENAME because of the fact that the username is part of the hash.
(We had always thought that was a bug^Wimplementation restriction,
but now it looks like a feature.) So in normal practice the above
hazard doesn't exist; but it would for cleartext passwords.
One thing we could do is *always* clear the password on RENAME.
Another is to keep the cleartext password, but pass the new name
and password through the plugin before allowing the RENAME to succeed.
Since the PW is cleartext, presumably the plugin won't have any problem
checking it. The latter however seems like we are getting a
security-critical behavior out of a chance combination of implementation
artifacts, which doesn't make me feel comfortable.
Thoughts?
regards, tom lane
