On 9/26/17, 2:38 AM, "Albe Laurenz" <laurenz.a...@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 > d960cb61b694cf459dcfb4b0128514c203937...@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_length passwordcheck.min_uppercase_letters passwordcheck.min_lowercase_letters passwordcheck.min_numbers passwordcheck.min_special_chars passwordcheck.special_chars passwordcheck.allow_username_in_password passwordcheck.use_cracklib Nathan -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers