Rejecting weak passwords
in [PgSql]
|
From: Dave Page on 14 Oct 2009 18:02 On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: > Dave Page <dpage(a)pgadmin.org> 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. > > Well, sure, but we're talking about a client going out of their way to > wrestle the point of the gun toward their own foot, aren't we? If > we're worried about the user compromising their own password, we have > bigger problems, like that slip of paper in their desk drawer with the > password written on it. I mean, I know some of these checklists can > be pretty brain-dead (I've been on both sides of the RFP process many > times), but it would seem over the top to say that client-side > password strength checks aren't OK for the reason you give. 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. -- 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: Bruce Momjian on 14 Oct 2009 18:07 Tom Lane wrote: > "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > > And, perhaps slightly off topic: if the login password is sent over a > > non-encrypted stream, md5sum or not, can't someone use it to log in if > > they're generating their own stream to connect? > > Not if they only capture a login exchange --- the password is doubly > encrypted during that. If they see the md5'd password in a CREATE USER > command, then yeah, they could pass a subsequent md5 challenge, using > suitably modified client software that doesn't try to re-encrypt the > given password. > > But the main point is to hide the cleartext password, in any case. What if we added a GUC that only allowed password changes via an SSL connection. You could say that is a security enhancement, and administrators could set up their systems to use 'password' authentication for SSL and check the password strength on the server because they come in clear-text. -- 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: Peter Eisentraut on 14 Oct 2009 18:12 On Wed, 2009-10-14 at 12:59 -0400, Tom Lane wrote: > If psql or pgAdmin takes a password and > then sends it in the clear without telling me, that's a breach of > trust > with potentially serious consequences. I might not trust the DBA, for > example, or I might be less confident of the network infrastructure > than he is. Well, you would lose anyway if the DBA switches the pg_hba.conf setting from md5 to password without telling you. There is usually no straightforward way in client applications to guard against that. Something to think about. -- 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 18:21 On 10/14/2009 05:33 PM, Dave Page wrote: > On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner > <Kevin.Grittner(a)wicourts.gov> wrote: > >> Can they check the box if the provided clients include password >> strength checking? I'm just wondering if we're going at this the hard >> way, if that really is the main goal. >> > 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? If the client is purposefully disabling passwords checks to use a "weak" password - this is an entirely different problem from somebody trying a weak password and being allowed. Circumvention of process is always a risk, and should be dealt with as a human resources problem. Why not stop the admin from disabling the security check when they create their pgadmin password too? We can't trust anybody - right? PAM does security checking client-side I think? I'm sure others do too? I'm not saying server checks are worthless - but I think you are exaggerating to say that client checks are worthless. Sending the password in cleartext via SQL seems bad. Sending it encoded seems only marginally better. Sending it in MD5 is good but means that password strength needs to be done by the client. You are saying that it's worth the loss of security in one area, to improve security in another. Providing client checks in the "official" clients is probably sufficient for your checkbox that you think is so important. Unless you think it is impossible to circumvent process in any of these "other" databases that do such a better job? Personally, I don't think PostgreSQL is the best place to manage passwords at this level anyways, beyond the basic usage. PostgreSQL shouldn't need to know the password, and the password should still be required to as strong as the organization requires it. Lots of other solutions here - PAM, LDAP, Kerberos, ... How much of these solutions should PostgreSQL re-implement? 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 18:23
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.) 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 |