Rejecting weak passwords
in [PgSql]
|
From: Dave Page on 15 Oct 2009 13:47 On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> If we were using some kind of real public key system and someone >> suggested breaking it to add password complexity checking, I would >> understand the outrage here. But I don't understand why everyone is >> so worked up about having an *optional* *flag* to force plaintext >> instead of MD5. I might be wrong here, but can't a determined >> attacker brute-force an MD5 anyway? The very fact that people are >> suggesting that password checking might be feasible even on a >> pre-MD5'd password by using a dictionary suggests that we're not >> getting a whole lot of real security here. And even if not, dude, >> it's an *optional* *flag*. > > Yes, and it's an optional flag that could perfectly well be implemented > in the plugin that I think we do have consensus to add a hook for. > The argument is over why do we need to litter the core system with it. I already said that would suit me. The only other requirement I would have is a way for pgAdmin or other clients to figure out if that flag was set so they could construct queries appropriately (and yes, that could include refusing to send plain text passwords over non-SSL connections). -- 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: Robert Haas on 15 Oct 2009 13:55 On Thu, Oct 15, 2009 at 1:47 PM, Dave Page <dpage(a)pgadmin.org> wrote: > On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas(a)gmail.com> writes: >>> If we were using some kind of real public key system and someone >>> suggested breaking it to add password complexity checking, I would >>> understand the outrage here. But I don't understand why everyone is >>> so worked up about having an *optional* *flag* to force plaintext >>> instead of MD5. I might be wrong here, but can't a determined >>> attacker brute-force an MD5 anyway? The very fact that people are >>> suggesting that password checking might be feasible even on a >>> pre-MD5'd password by using a dictionary suggests that we're not >>> getting a whole lot of real security here. And even if not, dude, >>> it's an *optional* *flag*. >> >> Yes, and it's an optional flag that could perfectly well be implemented >> in the plugin that I think we do have consensus to add a hook for. >> The argument is over why do we need to litter the core system with it. > > I already said that would suit me. The only other requirement I would > have is a way for pgAdmin or other clients to figure out if that flag > was set so they could construct queries appropriately (and yes, that > could include refusing to send plain text passwords over non-SSL > connections). OK, so we're in violent agreement here? Except for figuring out how an API for checking the flag? Could they just try it with MD5 first and then fall back if that say "no MD5"? ....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: Dave Page on 15 Oct 2009 14:02 On Thu, Oct 15, 2009 at 6:55 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > OK, so we're in violent agreement here? From a technical perspective I think we have been for a while. Though clearly some people disagree with my assertion that putting any form of policy enforcement in the client is not actually 'enforcement'. I wonder how many of those folks would implement their website's data sanitisation in the browser only - but I digress... :-) > Except for figuring out how > an API for checking the flag? Could they just try it with MD5 first > and then fall back if that say "no MD5"? That's what I was trying to avoid, as the architecture of pgAdmin makes that really hard. I know that's not PG's problem, but forcing a retry is quite an ugly solution anyway, so I was hoping we could come up with something better. I suppose in the worst case, I could just have pgAdmin throw the error, and then add a per-server option to disable password hashing in the relevant places, but I'd far rather have that automated so it can't be set unnecessarily. -- 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: Mark Mielke on 15 Oct 2009 14:11 On 10/15/2009 01:44 PM, Dave Page wrote: > I don't deal with prospective clients, which is where this comes from. > I do deal with a team of (pre)sales engineers who complain about this, > and maybe half-a-dozen other issues on a very regular basis. They tell > me that PostgreSQL loses out in early stages of tech evals because of > this issue, and I have no reason to disbelieve them. Sure it's almost > certainly not the only reason, but they add up. > A lot of evaluations are designed to fit exactly one product, and it's impossible to win here. In my own company, I recently saw the most ridiculous (to me) evaluations over a suite of products, that effectively listed an exact implementation as requirements. This resulted in a huge split between people who considered the evaluation fair and who went with their choice for exactly that one product, and the rest of the people who called the evaluation a sham and refused to participate, choosing to instead use their own choice of products not caring about the outcome of the evaluation. The evaluation, by the way, included other "silly" statements, like how a database instance costs $48k in license fees, even though everybody knew we were already using PostgreSQL for $0k or even if we chose to be supported by one of the many PostgreSQL support companies, it would not cost $48k. Where did they get that number? Because they presumed they would go with Oracle. The evaluation was a sham from start to finish. Perhaps you can see how little I value some arbitrary checkbox list on some "evaluation"? If people want to count PostgreSQL off the list from the start - they will, and there is not much you or I can do about it. Bowing to the pressure of fulfilling these checkboxes, when they'll just change them next time to something else that PostgreSQL doesn't quite do, is a waste of time. We should do what is right to do. We should not be focusing on checkboxes raised by other people who are not competent enough to understand the subject matter or who have already made their choice, and the evaluation is just a rubber stamp to pretend they have done due diligence about justifying their choice compared to alternatives. 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 15 Oct 2009 14:12
Dave Page <dpage(a)pgadmin.org> writes: > On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Yes, and it's an optional flag that could perfectly well be implemented >> in the plugin that I think we do have consensus to add a hook for. >> The argument is over why do we need to litter the core system with it. > I already said that would suit me. The only other requirement I would > have is a way for pgAdmin or other clients to figure out if that flag > was set so they could construct queries appropriately (and yes, that > could include refusing to send plain text passwords over non-SSL > connections). Well, if it's a GUC implemented by a plugin, it's still a GUC. All you need is some side agreement between pgAdmin and potential GUC authors about what the GUC will be called. 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 |