Rejecting weak passwords
in [PgSql]
|
From: Robert Haas on 14 Oct 2009 15:17 On Wed, Oct 14, 2009 at 1:48 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> 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). > >> It seems to me incredibly rare for anyone to issue a manual CREATE >> USER command with an encrypted password. And if it is generated by a >> script, it will presumably not have a trivial typographical error. > > Uh, this discussion was about cleartext passwords? I understand that. The point is, you seemed to be worried that log-obfuscation wouldn't work because someone might type "CREATD USER .... PASSWORD" rather than "CREATE USER ... PASSWORD". But this can happen today, too, can't it? The only difference is that today the password MIGHT be encrypted. But if the user is really entering the command manually, it's probably not. Sure, someone COULD pre-MD5 a string and then copy and paste it into a psql session, but I bet that's not too common. I suspect people using the pre-MD5 option are using a more sophisticated client of some sort anyway. ....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: Mark Mielke on 14 Oct 2009 15:20 On 10/14/2009 12:25 PM, Tom Lane wrote: > 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. It seems like the architectural problem here is that people think of SQL as being a valid way to change one's password. I never thought it was valid? What if, like "createdb", or "createuser", there was a "pgpasswd" that did all of the appropriate checks and provided the proper security (MD5 today?) during transit and when storing to a log file? "createuser" already does password prompting - maybe it should allow checking the password from the "createuser" client side? I think if we looked at the SQL commands as being a 'base operation not intended for everyday users', this entire debate would seem frivolous? :-) Does Oracle really do password checks on the base SQL commands used to change an Oracle password? That sounds silly. I'm totally on Tom's side. Having the server check passwords is the wrong solution to the problem. It makes things worse - not better. That they're approving a plugin capability on the server at all is generous, as it does lead to a sense of protection that may not be justifiable. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- 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 16:00 Dave Page <dpage(a)pgadmin.org> writes: > On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark <gsstark(a)mit.edu> wrote: >> This whole discussion seems very strange to me. Surely any >> organization with rules like this will want them to be system-wide and >> will have already implemented them in their PAM and LDAP systems >> (assuming their not using Kerberos or something like that anyways). > Because like it or not, this 'feature' is one that people *are* > looking for in early stages of evaluations, and it counts against us > and can hurt our adoption when we can't tick that box. Okay, fine, so we're not looking for actual high-grade security, we're looking to tick off a checkbox in the minds of not terribly well-informed people. Then the plugin mechanism as currently proposed will do the job just fine. We do not need to put a whole bunch of dubious extra infrastructure in there, and we DEFINITELY do not need anything that can be painted as a backwards step security-wise. 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 16:10 On Wed, Oct 14, 2009 at 9:00 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Okay, fine, so we're not looking for actual high-grade security, > we're looking to tick off a checkbox in the minds of not terribly > well-informed people. Then the plugin mechanism as currently proposed > will do the job just fine. We do not need to put a whole bunch of > dubious extra infrastructure in there, and we DEFINITELY do not need > anything that can be painted as a backwards step security-wise. Nice exit strategy :-) I said up front this was a box-ticking exercise for these folks, however, rather than just tick the box and move on (meh - who cares if we can store 2009-02-31 - it stores all the valid dates which are the ones that matter :-p ) I prefer to discuss the issue and do the best job we can to make it a practical, usable and useful feature - which is kinda what we usually pride ourselves in doing! -- 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 16:25
Dave Page <dpage(a)pgadmin.org> writes: > I said up front this was a box-ticking exercise for these folks, > however, rather than just tick the box and move on (meh - who cares if > we can store 2009-02-31 - it stores all the valid dates which are the > ones that matter :-p ) I prefer to discuss the issue and do the best > job we can to make it a practical, usable and useful feature - which > is kinda what we usually pride ourselves in doing! Well, sure. I just don't want to move backwards on other dimensions in order to move forward on this one. It's fair to argue that support of pre-crypted passwords closes only some holes that can be closed in other ways, but it's equally fair to argue that the limited capability of a plugin that has to check pre-crypted passwords also represents a corner case that can be solved in other ways. 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 |