Rejecting weak passwords
in [PgSql]
|
From: Dave Page on 14 Oct 2009 12:37 On Wed, Oct 14, 2009 at 5: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). > > 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. These are exactly the sort of issues I've been trying to get you to comment on. Thank you. > Marko has pointed out repeatedly that a plugin can catch the worst > cases of insecure passwords even when given a pre-md5'd password. My issues with that approach is that you may have to maintain a huge library of passwords - which you're never going to do efficiently or effectively if you assume that users may use simple variations of their username for example - eg. t0mlane. > 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. My only concern with that idea is having some way for the client to know when to not hash the password. Figuring that out from a specific error code and then retrying would be inefficient, ugly, and in the case of pgAdmin, quite hard to do given the way that SQL is generated and then executed. -- 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: Magnus Hagander on 14 Oct 2009 12:38 On Wed, Oct 14, 2009 at 18:25, 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). 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. So throwing out a wild idea that's probably just wild enough to even consider, but one way to deal with the logging side of things would be to deprecate/remove ALTER USER/CREATE USER with password, and add a separate API call. With a separate wire protocol packet. That would certainly take care of the logging part ;) > 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. Encryption policy of this type cannot be set at the server. Ever. And it shouldn't. If the sysadmin is worried someone might sniff the traffic, he should require SSL, or use a VPN, or similar things. If he's fine with letting the client decide, then it's not a problem, because it's up to the client not to send the password that way. And if the client did, well, the sysadmin just said it was ok to let the client decide, so we're ok. > 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. it lets you find some passwords, but it does not let you set a *policy*. As is often required by security policies etc. Does anybody know how other databases that *do* implement this solve the problem? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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:59 Dave Page <dpage(a)pgadmin.org> writes: > On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> 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. > My only concern with that idea is having some way for the client to > know when to not hash the password. Figuring that out from a specific > error code and then retrying would be inefficient, ugly, and in the > case of pgAdmin, quite hard to do given the way that SQL is generated > and then executed. I don't actually *want* client software deciding on its own hook to not hash the password. The only reason we have special client-side support for this command at all is to pre-hash the password, and people are accustomed to that behavior. 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. Fix pgAdmin so that this is a user-controlled switch and let the user read the plugin's error message and decide if he wants to retry with a non-encrypted password. 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: Tom Lane on 14 Oct 2009 13:08 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? The real point of crypted passwords is to not let uncrypted passwords go anywhere outside the *user's* control. If the DBA wants to enforce a policy that is incompatible with that, it should be extremely obvious to all concerned that that's what he's doing. In particular it should be in the user's face that he's about to send an uncrypted password, so that he can think twice about the particular password he's choosing (and hopefully not use one that's also good for another service). For relatively smart clients like pgAdmin, there might also be an option to refuse to send such a command across an insecure connection, or at least nag the user about it. 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: Bruce Momjian on 14 Oct 2009 13:28
nMagnus Hagander wrote: > > 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. > > it lets you find some passwords, but it does not let you set a > *policy*. As is often required by security policies etc. 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 #2 can be done by doing an MD5 on the server of the old password and comparing it to what the client sent --- no need for a client change there. #3 can be implemented in the server too. #1 could be implemented in the server without client change if you are willing to expand any wildcards in the password policy pattern, MD5 those, and check them against what was sent from the client, and this only happens during password change. However, that only can check for simplistic patterns, like trailing digit, etc, but not for things like upper/lower case usage, etc. If you have such a policy, aren't you already using LDAP or PAM, and can't those enforce it? -- 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 |