Nathan Bossart wrote:
>>>         passwordcheck.force_new_password
>> Does it mean a password different from the old one? +1. It could be
>> different from the last 3 passwords but we don't store a password
>> history.
> Yes.  As Michael pointed out, this might be better to do as a separate
> effort since we'll almost certainly need to introduce a way to store
> password history.

That increases the number of passwords stored on the server and
consequently the damage when that list is stolen.
Of course the old passwords are invalid, but if someone cracks them
they could still try them on other systems the person uses.

I think we should accept such a risk only if the benefits are clear, and
my opinion has always been that if you forbid password reuse, people
tend to come up with password generation schemes that are no better
than the original passwords.

> One interesting design challenge will be how to handle pre-hashed
> passwords, since the number of checks we can do on those is pretty
> limited.  I'm currently thinking of a parameter that can be used to
> block, allow, or force pre-hashed passwords.  If we take that route,
> perhaps we will also need to ensure that PostgreSQL fails to start when
> invalid combinations are specified (e.g. pre-hashed passwords are forced
> and min_password_length is nonzero).  Thoughts?

As was pointed out in the original discussion
the weak point of "passwordcheck" is that it does not work very well
for encrypted passwords.
The only saving grace is that you can at least check against
username equals password.

Disabling pre-hashed passwords in order to allow better password
checks is a problem rather than a solution, because it exposes you
to password theft of the clear-text password.  I think we shouldn't
go there.

The overall opinion in the above thread was that if you *really* care
about security, you don't use database passwords, but external
authentication with a centralized identity management system.

So I think it is fine to extend "passwordcheck", but we shouldn't
take it serious enough to reduce security elsewhere in order to
improve the module.

Laurenz Albe

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to