From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Euler Taveira <euler(at)timbira(dot)com(dot)br>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Enhancements to passwordcheck |
Date: | 2017-09-26 03:10:21 |
Message-ID: | 4FB1381C-CEAE-4053-8175-CAF14E8451B0@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/25/17, 8:31 PM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)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 !(at)#$%^&*()_+{}|<>?=. 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" <euler(at)timbira(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-09-26 03:17:54 | Re: Setting pd_lower in GIN metapage |
Previous Message | Masahiko Sawada | 2017-09-26 02:45:30 | Re: Replication status in logical replication |