Rejecting weak passwords
in [PgSql]
|
From: Bruce Momjian on 16 Oct 2009 11:29 Tom Lane 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. So, are we agreed to provide a hook on the server side, but to use it you have to configure your system with SSL and 'password'? I can add that to the TODO list. -- 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: Bruce Momjian on 16 Oct 2009 11:28 Dave Page wrote: > Too many of those caveats, and it's easy to see how we can be > discounted early in the evaluation phase. It's not helped that often > these lists will be drawn up by people used to working with the > commercial DBMSs, so we probably wouldn't get extra points for having > a dozen procedural languages, or other features that are largely > unique to PostgreSQL, no matter how cool and useful they are. Yep, this is illustrating something that is pretty basic to open source --- that is open source often provides the tools for a solution, rather than a complete solution. I often think of open source as providing a calculator with wires sticking out, rather than calculator buttons; the wires allow more flexibility, but they are harder to use. Personally I think the calculator/wires approach is better from an engineering perspective, but it can be a handicap in the user experience and checkbox categories --- ease of use is perhaps not our strong point. Much of our open source value is being different, in both cost, reliability, and configurability. -- 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: Tom Lane on 16 Oct 2009 11:58 Bruce Momjian <bruce(a)momjian.us> writes: > So, are we agreed to provide a hook on the server side, but to use it > you have to configure your system with SSL and 'password'? I can add > that to the TODO list. I think we're agreed to provide the hook. What restrictions the hook might enforce are not our concern. 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: Mark Mielke on 16 Oct 2009 12:40 On 10/16/2009 11:28 AM, Bruce Momjian wrote: > Dave Page wrote: > >> Too many of those caveats, and it's easy to see how we can be >> discounted early in the evaluation phase. It's not helped that often >> these lists will be drawn up by people used to working with the >> commercial DBMSs, so we probably wouldn't get extra points for having >> a dozen procedural languages, or other features that are largely >> unique to PostgreSQL, no matter how cool and useful they are. >> > Yep, this is illustrating something that is pretty basic to open source > --- that is open source often provides the tools for a solution, rather > than a complete solution. I often think of open source as providing a > calculator with wires sticking out, rather than calculator buttons; the > wires allow more flexibility, but they are harder to use. > Although often true - I think this is selling PostgreSQL a little short. It is a self-contained solution for what it does best, and for those that need more - there are better frameworks designed to be integrated that PostgreSQL is able to integrate with. PostgreSQL isn't a calculator with wires - if anything, I think PostgreSQL is an easy-to-use full functioned calculator whereas Oracle might be some advanced HP calculator that requires special training to learn how to use right... :-) > Personally I think the calculator/wires approach is better from an > engineering perspective, but it can be a handicap in the user experience > and checkbox categories --- ease of use is perhaps not our strong point. > Much of our open source value is being different, in both cost, > reliability, and configurability. I found this true of a lot of tools. I still remember when the mutt developers argued against putting IMAP in their solution because they thought there might be a better "IMAP component" client out there. Eventually, such arguments are dropped, as the practical sense on the matter says that tight integration is a requirement. I don't see how PostgreSQL has really failed in this regard. Maybe Oracle comes out-of-box with more features - but this doesn't make it necessarily a more "complete" solution - it just means it has more bells and whistles. A bicycle doesn't need a ticking card mounted through the spokes for it to be considered a "complete solution". :-) Somebody might one day want that "feature" - but it's extra - it's not core. 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: Greg Stark on 16 Oct 2009 13:06
On Fri, Oct 16, 2009 at 4:28 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Personally I think the calculator/wires approach is better from an > engineering perspective, but it can be a handicap in the user experience > and checkbox categories --- ease of use is perhaps not our strong point. > Much of our open source value is being different, in both cost, > reliability, and configurability. I don't really see this as an either-or proposition. The calculator with buttons still has wires inside, someone had to hack on the wiring to get the functionality working. Someone else with an inclination toward marketing put shiny buttons on it. I'm pretty happy to be in the first group and since Postgres has a BSD license people in the second group are free to work on shiny buttons. The discussion at hand is an unusual situation where the priorities conflict because supporting a particular shiny button requires ripping out some useful wiring. In the long run I think having the wiring right is more valuable than some shiny buttons today. -- 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 |