Rejecting weak passwords
in [PgSql]
|
From: Peter Eisentraut on 19 Oct 2009 07:51 On Mon, 2009-10-19 at 09:14 +0200, Albe Laurenz wrote: > 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. Note that this solution will still not satisfy the original checkbox requirement. -- 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 08:54 Peter Eisentraut wrote: >> 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. > > Note that this solution will still not satisfy the original checkbox > requirement. I guess I misunderstood something there, but I had assumed that the checkbox item read something like: "Does the product offer password policy enforcement?" (to quote Dave Page). I understood that to mean "does the server check if a new password complies with a certain set of rules". 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: Robert Haas on 19 Oct 2009 10:07 On Mon, Oct 19, 2009 at 7:34 AM, Peter Eisentraut <peter_e(a)gmx.net> wrote: > 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. Unless you have the ability to entirely control the software that users use to access PostgreSQL, which is probably only true in super-high-security environments and is certainly false anywhere I've ever worked, you can only have one of those things. SSH keys or SSL certificates are great for defeating network attacks, but I know a lot of people who keep SSL certificates unencrypted on their laptops because there's no easy way to stop them. Those very same people can EASILY be forced to pick relatively good Windows logon passwords because AD can enforce password complexity requirements. Of course, they can't be forced not to write their Windows logon password on a napkin, but they also can't be forced not to run an unsecured FTP server on their laptop that provides access to their unencrypted SSH keys/SSL certificates. Now, we can argue all day about probabilities, but I don't see any reason to believe that we know for sure what the best trade-off is in every environment, which is why I favor providing options, documenting the trade-offs, and letting users make the final decision. ....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: Tom Lane on 19 Oct 2009 10:30 "Albe Laurenz" <laurenz.albe(a)wien.gv.at> writes: > Bruce Momjian wrote: >> 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. > 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. Actually, not one word of *either* version should be in TODO. All of that is speculation about policies that a particular add-on module might or might not choose to enforce. 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: Peter Eisentraut on 19 Oct 2009 12:08
On Mon, 2009-10-19 at 14:54 +0200, Albe Laurenz wrote: > Peter Eisentraut wrote: > > Note that this solution will still not satisfy the original checkbox > > requirement. > > I guess I misunderstood something there, but I had assumed that the > checkbox item read something like: "Does the product offer password > policy enforcement?" (to quote Dave Page). The answer to that is currently "Yes, with external tools". Using the plugin approach, the answer will remain "Yes, with external tools". So we wouldn't gain much. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |