Bossart, Nathan wrote: > On 9/27/17, 7:41 AM, "Peter Eisentraut" <peter.eisentr...@2ndquadrant.com> > wrote: > > On 9/25/17 23:10, Bossart, Nathan wrote: > >> 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. > > > > Pre-hashed passwords are the normal case. You can't break that without > > making this module a net loss in security. > > A strength in making this configurable is that you could use it to > enforce that passwords are pre-hashed. But yes, blocking pre- > hashed passwords could be undesirable given an untrusted network or > server.
I think a password strength check must live at the end that does the encryption -- something like in psql when you do the \password command, *before* the encrypted password is sent to the server. Then you can do all sort of stuff (... except check for password history). I think the passwordcheck module as a whole is a dead end, security- wise. Myself, I've never seen the point in it. It runs at the wrong time, and there's no way to fix that. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
