Re: [HACKERS] Enhancements to passwordcheck

On 9/26/17, 2:38 AM, "Albe Laurenz" <laurenz.albe@wien.gv.at> wrote:
> 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.

Right.  However, without this, they may not change the password at
all, which would make the expiry functionality less effective.  I
suppose there's not a great way to guard against these sorts of
password generation schemes without being able to judge the proposed
password against the previous password, too.

Perhaps the max_expiry_period parameter should be left out for now
as well.

>> 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
> D960CB61B694CF459DCFB4B0128514C203937F49@exadv11.host.magwien.gv.at
> 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.

Thanks for linking the original thread.  There are a lot of
interesting points.  I wonder if enhanced password checking in core
or contrib might be received differently with the introduction of
SCRAM authentication, since the weaknesses of MD5 were often cited.

> 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.

I understand the points made here, but not allowing configurability
here really hinders the module's ability to enforce much of
anything.  However, I did say I wanted to avoid controversial
parameters, so I'll plan to count this one out as well.

This leaves us with the following proposed parameters for now:

passwordcheck.min_password_lengthpasswordcheck.min_uppercase_letterspasswordcheck.min_lowercase_letterspasswordcheck.min_numberspasswordcheck.min_special_charspasswordcheck.special_charspasswordcheck.allow_username_in_passwordpasswordcheck.use_cracklib

Nathan


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers