Thread: [HACKERS] Enhancements to passwordcheck
Hi hackers, Currently, the passwordcheck module provides a few basic checks to strengthen passwords. However, any configuration must be ready at compile time, and many common password requirements cannot be enforced without creating a custom version of this module. I think there are a number of useful parameters that could be added to enable common password restrictions, including the following list, which is based on some asks from our customers: passwordcheck.min_password_lengthpasswordcheck.min_uppercase_letterspasswordcheck.min_lowercase_letterspasswordcheck.min_numberspasswordcheck.min_special_charspasswordcheck.superuser_can_bypasspasswordcheck.max_expiry_periodpasswordcheck.force_new_password 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. Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Sep 26, 2017 at 3:04 AM, Bossart, Nathan <bossartn@amazon.com> wrote:
> Currently, the passwordcheck module provides a few basic checks to strengthen
> passwords. However, any configuration must be ready at compile time, and many
> common password requirements cannot be enforced without creating a custom
> version of this module.
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.
> I think there are a number of useful parameters that
> could be added to enable common password restrictions, including the following
> list, which is based on some asks from our customers:
>
> passwordcheck.min_password_length
Okay. I have that as well.
> passwordcheck.min_uppercase_letters
> passwordcheck.min_lowercase_letters
> passwordcheck.min_numbers
Those map with isdigit(), isupper() and islower(). Exactly what I have.
> passwordcheck.min_special_chars
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.
> passwordcheck.superuser_can_bypass
Not sure that this one has much meaning. Superusers could easily
unload the module.
> passwordcheck.max_expiry_period
Okay. valid_until is passed down to the password hook.
> 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.
> 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.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2017-09-25 15:04 GMT-03:00 Bossart, Nathan <bossartn@amazon.com>: > Currently, the passwordcheck module provides a few basic checks to strengthen > passwords. However, any configuration must be ready at compile time, and many > common password requirements cannot be enforced without creating a custom > version of this module. I think there are a number of useful parameters that > could be added to enable common password restrictions, including the following > list, which is based on some asks from our customers: > > passwordcheck.min_password_length > passwordcheck.min_uppercase_letters > passwordcheck.min_lowercase_letters > passwordcheck.min_numbers > passwordcheck.min_special_chars > +1. > passwordcheck.superuser_can_bypass > It is not clear if it will bypass the checks for (i) a new superuser or (ii) a superuser creating a new role. I wouldn't recommend using such option even tough it is a common practice. > 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). > 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. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 9/25/17, 8:31 PM, "Michael Paquier" <michael.paquier@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" <euler@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
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. > 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. 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. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
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
Nathan Bossart wrote: >> 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. I had the impression that the reasons why database passwords are not the best option for high security were: 1) The password hash is stored in the database and can be stolen and cracked (don't know if dictionary attacks are harderwith SCRAM). 2) The password or the password hash are transmitted to the server when you change the password and may be captured. >> 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. I agree that it is a good thing to make "passwordcheck" configurable. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 27, 2017 at 6:05 PM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote: > I had the impression that the reasons why database passwords are > not the best option for high security were: > 1) The password hash is stored in the database and can be stolen and > cracked (don't know if dictionary attacks are harder with SCRAM). > 2) The password or the password hash are transmitted to the server > when you change the password and may be captured. Having a MD5 hash is enough to connect to the database. No need to crack it. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
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. -- Peter Eisentraut http://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
On 9/27/17, 7:41 AM, "Peter Eisentraut" <peter.eisentraut@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. Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Bossart, Nathan wrote: > On 9/27/17, 7:41 AM, "Peter Eisentraut" <peter.eisentraut@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
On Thu, Sep 28, 2017 at 12:06 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > 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. Client commands may be run on a trusted network as well, let's not forget that. But I definitely agree that this is bad practice in general to not hash passwords beforehand. Another thing that passwordcheck is good at is being an example of hook use. I would think that many people refer to it when implementing their own module for whatever they want. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier wrote: > On Thu, Sep 28, 2017 at 12:06 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: >> 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. > > Client commands may be run on a trusted network as well, let's not > forget that. But I definitely agree that this is bad practice in > general to not hash passwords beforehand. Another thing that > passwordcheck is good at is being an example of hook use. I would > think that many people refer to it when implementing their own module > for whatever they want. Right. I originally only wanted the hook, but was lobbied into writing the contrib module as well, to a) have a nice checkbox item for ill-concieved security check lists b) have an example of how the hook could be used. I still think that there is nothing wrong with adding some GUCs to the module, as long as there is nothing in it that can compromise overall security. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier wrote: > Client commands may be run on a trusted network as well, let's not > forget that. I've never seen this "trusted network" thing of which you speak. Is it nice? -- Á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
On Fri, Sep 29, 2017 at 3:17 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
Michael Paquier wrote:
> Client commands may be run on a trusted network as well, let's not
> forget that.
I've never seen this "trusted network" thing of which you speak. Is it
nice?
I believe it's usually referred to as "localhost"?
On 9/25/17 14:04, Bossart, Nathan wrote: > 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. This thread has no patch, which is not really the intended use of the commit fest, so I'm closing the commit fest entry for now. -- Peter Eisentraut http://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
On 11/1/17, 9:33 PM, "Peter Eisentraut" <peter.eisentraut@2ndquadrant.com> wrote: > On 9/25/17 14:04, Bossart, Nathan wrote: >> 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. > > This thread has no patch, which is not really the intended use of the > commit fest, so I'm closing the commit fest entry for now. Sorry about that. I'll reopen it when I have a patch to share. Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers