Rejecting weak passwords
in [PgSql]
|
From: Stephen Frost on 14 Oct 2009 18:44 * Tom Lane (tgl(a)sss.pgh.pa.us) wrote: > Peter Eisentraut <peter_e(a)gmx.net> writes: > > Well, you would lose anyway if the DBA switches the pg_hba.conf setting > > from md5 to password without telling you. > > True :-(. Anybody for a zero-knowledge protocol? > > (Realistically, non-password-based auth methods are the only real > solution here, I fear. We should probably be doing more to encourage > people to use SSL-cert-based authentication in low-trust situations.) Or GSSAPI.. Helping users understand how they can leverage their existing Kerberos or MS SSPI single-sign-on infrastructures to securely access PG would go a long way to reducing the password-based usage out there, imo. Of course, it'd be nice if we supported GSSAPI encrypted transport too. Separating the encryption into SSL is less than ideal. Stephen
From: Dave Page on 15 Oct 2009 03:54 On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielke <mark(a)mark.mielke.cc> wrote: > On 10/14/2009 05:33 PM, Dave Page wrote: >> >> No. Any checks at the client are worthless, as they can be bypassed by >> 10 minutes worth of simple coding in any of a dozen or more languages. >> > > Why care? Because many large (and small for that matter) organisations also have security policies which mandate the enforcement of specific password policies. Just because you think it's worthless to try to prevent someone reusing a password, or using 'password' doesn't mean that everyone else does. Some organisations will use such a feature in a box-ticking exercise when evaluating, and others may actually decide to use the feature, and expect it to work effectively. Beside, we are not in the habit of putting half-arsed features in PostgreSQL. If we do something, we do it properly. -- 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 15 Oct 2009 04:00 On Wed, Oct 14, 2009 at 11:44 PM, Stephen Frost <sfrost(a)snowman.net> wrote: > * Tom Lane (tgl(a)sss.pgh.pa.us) wrote: >> Peter Eisentraut <peter_e(a)gmx.net> writes: >> > Well, you would lose anyway if the DBA switches the pg_hba.conf setting >> > from md5 to password without telling you. >> >> True :-(. Anybody for a zero-knowledge protocol? >> >> (Realistically, non-password-based auth methods are the only real >> solution here, I fear. We should probably be doing more to encourage >> people to use SSL-cert-based authentication in low-trust situations.) > > Or GSSAPI.. Helping users understand how they can leverage their > existing Kerberos or MS SSPI single-sign-on infrastructures to securely > access PG would go a long way to reducing the password-based usage out > there, imo. Of course, it'd be nice if we supported GSSAPI encrypted > transport too. Separating the encryption into SSL is less than ideal. Such solutions are exactly what I'd expect to actually go into production in most places, but that doesn't mean that people don't pay attention to the basic features offered as part of the core database when they're early in the evaluation phase. -- 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: "Kevin Grittner" on 15 Oct 2009 09:49 Dave Page <dpage(a)pgadmin.org> wrote: > On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner >> bigger problems, like that slip of paper in their desk drawer with >> the password written on it. > See my previous comment about dates. Check-box items aside, I have > absolutely no desire to try to give the illusion of a security > feature, when in reality any user could easily bypass it. I think you missed my point -- if you want to try to block the user from compromising their *own* password, you can't. They can tell anybody they want, write it on a slip of paper stuck to their terminal (yes, I've seen that), let it loose any other way they want. Why focus on one (rather unlikely) way that a user could compromise their own password when there are so many other ways, much easier and more likely to actually happen, which are totally out of our control? If a simple client-side strength check would allow the box to be checked, and would protect any user who isn't going out of their way to let their password be abused, I'm not really understanding your objection. Now, if it fails to cover the checkbox because it can't check against the last three passwords used, that's another story, but the server-side plugin can easily cover things like that. And ultimately, if you really care about tight security rather than checking off a box, other posts address how that can actually be done. -Kevin -- 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 15 Oct 2009 10:08
On Thu, Oct 15, 2009 at 2:49 PM, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: > Dave Page <dpage(a)pgadmin.org> wrote: >> On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner > >>> bigger problems, like that slip of paper in their desk drawer with >>> the password written on it. > >> See my previous comment about dates. Check-box items aside, I have >> absolutely no desire to try to give the illusion of a security >> feature, when in reality any user could easily bypass it. > > I think you missed my point -- if you want to try to block the user > from compromising their *own* password, you can't. They can tell > anybody they want, write it on a slip of paper stuck to their terminal > (yes, I've seen that), let it loose any other way they want. Why > focus on one (rather unlikely) way that a user could compromise their > own password when there are so many other ways, much easier and more > likely to actually happen, which are totally out of our control? It's certainly true that there are other ways for users to compromise their passwords if they want. The fact remains though, that most other DBMSs (and all major operating systems I can think of) offer password policy features as non-client checks which are difficult, if not impossible for the user to bypass. Clearly other people think it's important to do this, and we are compared against their products on a daily basis, so if we want to compete with them on a level playing field we need at least a comparable feature set. -- 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 |