Rejecting weak passwords
in [PgSql]
|
From: Robert Haas on 14 Oct 2009 13:38 On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 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). 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. > 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. Using a non-SSL connection over an untrusted network is incredibly stupid to begin with. I'm not sure we should be basing our design decisions around that scenario. ....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 13:48 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? 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: Greg Stark on 14 Oct 2009 14:42 On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian <bruce(a)momjian.us> wrote: > > I see three checks we are trying to do on passwords: > > 1) Password complexity enforcement/policies > 2) Password history - you can't reuse a password > 3) Account disable after X incorrect attempts 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). There's not much point in reinventing the wheel in the database when a) we'll never be remotely as complete as the existing authentication systems -- the above requirements only barely scratch the surface and b) even if we were as complete as existing systems it would never be integrated so there would be nothing stopping people from reusing passwords from their login account or trying passwords a limited number of times against each system to get many attempts in total. Incidentally I'm extremely dubious of systems that implement your goal #3. It seems like more of an obvious DOS attack vector than a security improvement to me. There are better defense mechanisms for such attacks such as preauth. One more argument why we shouldn't be reimplementing the wheel in an area where don't have particularly good experience. -- greg -- 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 14:50 On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark <gsstark(a)mit.edu> wrote: > On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian <bruce(a)momjian.us> wrote: >> >> I see three checks we are trying to do on passwords: >> >> 1) Password complexity enforcement/policies >> 2) Password history - you can't reuse a password >> 3) Account disable after X incorrect attempts > > > 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. As an example, after years of only offering password policy management via the NT domain/active directory authentication methods, even Microsoft finally gave in and added policy management for their SQL Server accounts with SQL 2k5. -- 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: Dave Page on 14 Oct 2009 14:56
On Wed, Oct 14, 2009 at 6:08 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Magnus Hagander <magnus(a)hagander.net> writes: >> On Wed, Oct 14, 2009 at 18:25, 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). > >> I'm unsure if it's our responsibility to think about that. We can leak >> a *lot* of sensitive information to the logs through syntax errors, >> this is just one of them. We *do* need to worry about the statements >> when they are sent properly, of course. > > Even if they're "sent properly", this entire discussion misses the point. > The reason to not want cleartext passwords in the logs is that the user > doesn't trust the DBA. Why would a user who doesn't trust the DBA > want to trust him to not be running a modified copy of the database with > all this nice logic disabled? If you trust him that little, why would you use a password that you also use elsewhere? Besides, if he can run a modified version of the database, its game over anyway. Just set pg_hba.conf's auth method to password, and you don't even have to wait for the user to change their password - you can grab it the next time he logs in. -- 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 |