Rejecting weak passwords
in [PgSql]
|
From: Dave Page on 14 Oct 2009 11:44 On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Dave Page <dpage(a)pgadmin.org> writes: >> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> If you're really intent on making that happen, you can have your >>> password checker plugin reject crypted passwords; we don't need >>> such a questionable rule in core. > >> Client software would need to have a standard way to know when to use >> ENCRYPTED PASSWORD or not. > > Oh, so you want us to propagate extra support for this blatant security > reduction all over the system too? No thank you. You've twice asserted it's a reduction without providing any arguments to back that up. I argue that you *possibly* open a very hard to exploit hole, which is exploitable only by sysadmins/DBAs, in return for which you close a very large hole that allows users to reuse passwords or use common or easy to guess words. If I am incorrect or have missed an important point, please explain why or what. > This whole line of discussion just proves the point that was made > originally: it would be a lot better to do whatever checking you want > done on the client side, rather than risk transmitting unencrypted > passwords. If you are going to imagine that client-side software knows > about such a GUC, you might as well imagine that they have cracklib > built in. Surely you can see that it is *absolutely pointless* to put an password complexity checking in the client? All a user would need to do is grab a copy of psql to bypass it. If they can't do that, there's probably a scripting language or 12 that would make it similarly easy. -- 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
From: Robert Haas on 14 Oct 2009 11:53 On Wed, Oct 14, 2009 at 11:44 AM, Dave Page <dpage(a)pgadmin.org> wrote: > On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Dave Page <dpage(a)pgadmin.org> writes: >>> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>>> If you're really intent on making that happen, you can have your >>>> password checker plugin reject crypted passwords; we don't need >>>> such a questionable rule in core. >> >>> Client software would need to have a standard way to know when to use >>> ENCRYPTED PASSWORD or not. >> >> Oh, so you want us to propagate extra support for this blatant security >> reduction all over the system too? No thank you. > > You've twice asserted it's a reduction without providing any arguments > to back that up. I argue that you *possibly* open a very hard to > exploit hole, which is exploitable only by sysadmins/DBAs, in return > for which you close a very large hole that allows users to reuse > passwords or use common or easy to guess words. > > If I am incorrect or have missed an important point, please explain why or what. > >> This whole line of discussion just proves the point that was made >> originally: it would be a lot better to do whatever checking you want >> done on the client side, rather than risk transmitting unencrypted >> passwords. If you are going to imagine that client-side software knows >> about such a GUC, you might as well imagine that they have cracklib >> built in. > > Surely you can see that it is *absolutely pointless* to put an > password complexity checking in the client? All a user would need to > do is grab a copy of psql to bypass it. If they can't do that, there's > probably a scripting language or 12 that would make it similarly easy. To all of the above, +1. ....Robert -- 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: Tom Lane on 14 Oct 2009 12:08 Dave Page <dpage(a)pgadmin.org> writes: > You've twice asserted it's a reduction without providing any arguments > to back that up. You quoted two good arguments why it's insecure in your original message, neither of which your proposed GUC does anything to protect against; and you also admitted that there might be other leakage paths we haven't thought of. That seems to me to be more than sufficient reason to not encourage people to go back to passing unencrypted passwords around. regards, tom lane -- 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: Dave Page on 14 Oct 2009 12:16 On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Dave Page <dpage(a)pgadmin.org> writes: >> You've twice asserted it's a reduction without providing any arguments >> to back that up. > > You quoted two good arguments why it's insecure in your original > message, neither of which your proposed GUC does anything to protect > against; I see one, and I proposed masking passwords in any relevant queries before they were written to the stats or logs to mitigate that. > and you also admitted that there might be other leakage paths > we haven't thought of. That seems to me to be more than sufficient > reason to not encourage people to go back to passing unencrypted > passwords around. Yes. Which is why I asked your opinion as there's a far greater chance you would know of any such paths than I, *and* whether they represent a greater risk than the complete lack of control over the effectiveness of users passwords that we currently have. -- 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
From: Tom Lane on 14 Oct 2009 12:25
Dave Page <dpage(a)pgadmin.org> writes: > On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > I see one, and I proposed masking passwords in any relevant queries > before they were written to the stats or logs to mitigate that. Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to throw a syntax error before you realize there's anything there that might need to be protected). And you ignored the question of insecure transmission pathways, anyway. By the time the backend has figured out that it's got a CREATE USER .... PASSWORD command, it's already way too late if the client sent it over a non-SSL connection. Marko has pointed out repeatedly that a plugin can catch the worst cases of insecure passwords even when given a pre-md5'd password. So you can use a plugin that does it that way, or if you want you can use a plugin that throws error on a pre-md5'd password. I do not see a reason for us to add a boatload of questionable logic that favors the latter approach. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |