On 9/25/17, 8:31 PM, "Michael Paquier" <michael.paqu...@gmail.com> wrote: > Yes, I have developped a couple of years back a fork of passwordcheck > which had much similar enhancements, so getting something more modular > in upstream would be really welcome.
Awesome. > On top of that I think that you should have a parameter that specifies > a string full of special characters. For example I have been using > things like !@#$%^&*()_+{}|<>?=. But you likely want to make that > modular, people have their own set of character characters, and it is > just something that could be compared with strchr(), still the default > should be meaningful. +1 >> passwordcheck.superuser_can_bypass > > Not sure that this one has much meaning. Superusers could easily > unload the module. True. I can leave it out for now. >> passwordcheck.force_new_password > > So this is to make sure that the new password is not the same as the > old one? This would be better with the last N passwords, still this > would require more facilities. I would discard this one as what you > are proposing here is not modular enough IMO, and needs a separate > feature set. Fair enough. I'll definitely start with a set of very non-controversial parameters, as this will likely require rewriting most of the module. >> I'd like to use this thread to gauge community interest in adding this >> functionality to this module. If there is interest, I'll add it to the next >> commitfest. > > I think that's a good idea. Great to see that you are contributing > back some stuff. Thanks for the detailed feedback. On 9/25/17, 8:37 PM, "Euler Taveira" <eu...@timbira.com.br> wrote: >> passwordcheck.max_expiry_period >> > How would you enforce that? If the password expires, you can log in to > change the password. If you let him/her to get in and change the > password, you can't obligate the user to do that. You could send a > message to remember that the password will expire but you can't > enforce that (unless you make a change in the protocol). My idea was to tie into the existing password expiration functionality (VALID UNTIL in CREATE/ALTER ROLE statements). I don't think this would involve any changes to how password expiration works. Instead, it would just be a simple check to make sure the specified expiration date is not too far in the future. >> 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. 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? Also, I imagine we'll want to keep the cracklib and "password cannot contain role name" features around, although perhaps these could become configurable like the rest of the options. Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers