Rejecting weak passwords
in [PgSql]
|
From: Bruce Momjian on 2 Oct 2009 18:56 Tom Lane wrote: > Magnus Hagander <magnus(a)hagander.net> writes: > > That said, it would still be good to have something actually *useful* > > in contrib. A bit more than just comparing userid and password. > > Perhaps at least being able to set the min length, and the requirement > > on having >1 "character class"? > > +1. There's still the issue of not being able to do much with a > pre-MD5'd password, though. Agreed. I am still a little worried that people will think they are checking for weak passwords when, for MD5, they are not. I am also worried that people will unknowingly reduce their security (not use MD5) to allow weak password checking. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Albe Laurenz" on 3 Oct 2009 05:03 Bruce Momjian wrote: >Tom Lane wrote: >> > That said, it would still be good to have something actually *useful* >> > in contrib. A bit more than just comparing userid and password. >> > Perhaps at least being able to set the min length, and the requirement >> > on having >1 "character class"? >> >> +1. There's still the issue of not being able to do much with a >> pre-MD5'd password, though. > > Agreed. I am still a little worried that people will think they are > checking for weak passwords when, for MD5, they are not. I am also > worried that people will unknowingly reduce their security (not use MD5) > to allow weak password checking. I will write a contrib that does some password checking. I'll add comments to the code to show where and how to add cracklib if you want to. I will write a conspicuous noisy warning into the README that warns about the limits with respect to MD5 and states that for really good security you should consider external authentication. Due to time constraints at work I won't be able to start working on it before end of next week. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Albe Laurenz" on 9 Oct 2009 07:47 Following the discussions in http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php and http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php , here are patches for a) a hook in backend/commands/user.c that allows one to add password checking functions b) a contrib module that makes use of the hook and c) documentation for the contrib module. I'll add links to the November commitfest page. Yours, Laurenz Albe
From: "Albe Laurenz" on 12 Oct 2009 02:22 I wrote: > Following the discussions in > http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php > and > http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php , > here are patches for > > a) a hook in backend/commands/user.c that allows one to add > password checking functions > b) a contrib module that makes use of the hook and > c) documentation for the contrib module. I found a small but embarrassing bug - here is another version. Yours, Laurenz Albe
From: Dave Page on 14 Oct 2009 10:27
On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> IOW, having plaintext password in CREATE/ALTER time which can >> then checked for weaknesses is better that MD5 password, which >> actually does not increase security. > > This is not acceptable and will not happen. The case that ENCRYPTED > protects against is database superusers finding out other users' > original passwords, which is a security issue to the extent that those > users have used the same/similar passwords for other systems. > We're not going to give up protection for that in order to provide > an option to do weak-password checking in a place that simply isn't > the best place to do it anyway. This is an area in which we often get beaten up in in technical evaluations against other DBMSs. Password complexity checks are pretty much standard features in other products and it hurts our adoption not to be able to offer them, especially in large shops where the first phase of the eval may be a simple box-checking exercise. I would suggest that in addition to the proposed plugin, we add an suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED PASSWORD to ensure that the password complexity can be checked when roles are created or modified. In the default case, the current behaviour would not change. With the GUC turned on, passwords could be forced through the validation module. To allow dumps to remain secure, the GUC can be turned off by the DBA prior to loading, or in the dump itself. Logging of CREATE/ALTER users statements in this mode could be special-cased to prevent passwords going to the logs/stats (not sure what overhead that might incur though). In addition, the docs for the GUC would obviously point out that it should only be used in conjunction with SSL connections. This would allow us to remain secure-by-default, and yet offer an important option for many potential users. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |