Rejecting weak passwords
in [PgSql]
|
From: Tom Lane on 19 Oct 2009 12:12 Peter Eisentraut <peter_e(a)gmx.net> writes: > On Mon, 2009-10-19 at 14:54 +0200, Albe Laurenz wrote: >> 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. Except that your first statement is false. It is not possible currently for any tool to prevent someone from doing ALTER USER joe PASSWORD joe. A server-side plugin can provide a guarantee that there are no bad passwords (for some value of bad, and with some possible adverse consequences). We don't have that today. 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: Alvaro Herrera on 19 Oct 2009 12:23 Tom Lane escribi�: > Peter Eisentraut <peter_e(a)gmx.net> writes: > > On Mon, 2009-10-19 at 14:54 +0200, Albe Laurenz wrote: > >> 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. > > Except that your first statement is false. It is not possible currently > for any tool to prevent someone from doing ALTER USER joe PASSWORD joe. > A server-side plugin can provide a guarantee that there are no bad > passwords (for some value of bad, and with some possible adverse > consequences). We don't have that today. We do, if you have you server grabbing passwords from LDAP or whatever external auth service you use. That would be more secure than anything mentioned in this thread, because the password enforcement could work on unencrypted passwords without adverse consequences. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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: Andrew Dunstan on 19 Oct 2009 12:37 Alvaro Herrera wrote: >> Except that your first statement is false. It is not possible currently >> for any tool to prevent someone from doing ALTER USER joe PASSWORD joe. >> A server-side plugin can provide a guarantee that there are no bad >> passwords (for some value of bad, and with some possible adverse >> consequences). We don't have that today. >> > > We do, if you have you server grabbing passwords from LDAP or whatever > external auth service you use. That would be more secure than anything > mentioned in this thread, because the password enforcement could work on > unencrypted passwords without adverse consequences. > We don't have it today for passwords that postgres manages. Unless we're going to rely on an external auth source completely, I think there's a good case for the hooks, but not for any of the other "adjustments" that people have suggested. cheers andrew -- 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 12:37 I wrote: > A server-side plugin can provide a guarantee that there are no bad > passwords (for some value of bad, and with some possible adverse > consequences). We don't have that today. BTW, it strikes me that ALTER USER RENAME introduces an interesting hazard for such a plugin. Consider CREATE USER joe; ALTER USER joe PASSWORD joe; -- presumably, plugin will reject this ALTER USER joe PASSWORD mumblefrotz; -- assume this is considered OK ALTER USER joe RENAME TO mumblefrotz; Now we have a user with name equal to password, which no sane security policy will think is a good thing, but the plugin had no chance to prevent it. In the case where the password is stored MD5-crypted, we clear it on RENAME because of the fact that the username is part of the hash. (We had always thought that was a bug^Wimplementation restriction, but now it looks like a feature.) So in normal practice the above hazard doesn't exist; but it would for cleartext passwords. One thing we could do is *always* clear the password on RENAME. Another is to keep the cleartext password, but pass the new name and password through the plugin before allowing the RENAME to succeed. Since the PW is cleartext, presumably the plugin won't have any problem checking it. The latter however seems like we are getting a security-critical behavior out of a chance combination of implementation artifacts, which doesn't make me feel comfortable. Thoughts? 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 19 Oct 2009 13:16
Andrew Dunstan <andrew(a)dunslane.net> writes: > Alvaro Herrera wrote: >> We do, if you have you server grabbing passwords from LDAP or whatever >> external auth service you use. That would be more secure than anything >> mentioned in this thread, because the password enforcement could work on >> unencrypted passwords without adverse consequences. > We don't have it today for passwords that postgres manages. Unless we're > going to rely on an external auth source completely, I think there's a > good case for the hooks, but not for any of the other "adjustments" that > people have suggested. Yeah. Installing LDAP or Kerberos or whatever is sensible if you have a need for a central auth server anyway. If you are just trying to run a database, it's a major additional investment of effort, and I can't quibble at all with people who think that it's unreasonable to have to do that just to have some modicum of a password policy. I also am of the opinion that it's reasonable to provide a hook or two for this purpose, but not to go further than that. 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 |