Rejecting weak passwords
in [PgSql]
|
From: Bruce Momjian on 16 Oct 2009 13:34 Tom Lane wrote: > 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. Great, added to TODO: Allow server-side enforcement of password policies Password checks might include password complexity or non-reuse of passwords. This facility will require the client to send the password to the server in plain-text, so SSL and 'password' authentication is necessary to use this features. * http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php * http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php -- 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 13:40 Mark Mielke 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 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. Agreed. Many commercial database solutions start to look like Frankenstein with all the bolted-on components. -- 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: Ron Mayer on 18 Oct 2009 12:17 Bruce Momjian wrote: > 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. I disagree. Open source typically provides the complete solution too - just not from the developer who programs one component of the solution. Checklist writers intentionally use this to make straw-man arguments. People used to say "linux doesn't even have a GUI" - noting that X11 is a separate project. Now people have database checkboxes for: * a GUI admin tool (which we have, though it's a separate package) * GIS data types (which we have, though it's a separate package) * server-side password filters (which we have, though LDAP, etc) * replication (which we have, though many packages) * clustering (which we have, though hadoopdb) The Linux guys successfully communicated that it isn't fair for checklists to compare an OS kernel against commercial application suites. Seems it'd be good for the postgres project to similarly communicate that the database kernel is the core of a platform that's broader than just a database kernel. Ron -- 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: "Albe Laurenz" on 19 Oct 2009 03:14 Bruce Momjian wrote: > Great, added to TODO: > > Allow server-side enforcement of password policies > > Password checks might include password complexity or non-reuse of > passwords. This facility will require the client to send the password to > the server in plain-text, so SSL and 'password' authentication is > necessary to use this features. I don't get why you need 'password' authentication for that. The point where the password should be checked is not when the user uses it to logon, but when he or she changes it. So in my opinion that should be: This facility will require to send new and changed password to the server in plain-text, so it will require SSL, and the use of encrypted passwords in CREATE/ALTER ROLE will have to be disabled. Yours, Laurenz Albe -- 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 19 Oct 2009 07:34
On Thu, 2009-10-15 at 13:19 -0400, Robert Haas wrote: > But I don't understand why everyone is > so worked up about having an *optional* *flag* to force plaintext > instead of MD5. It would be pretty bad usability. Users would be faced with the choice: you can have secure authentication or good passwords, but not both. (For some values of "secure" and "good".) I think most people would want both. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |