Rejecting weak passwords
in [PgSql]
|
From: Bruce Momjian on 20 Oct 2009 00:08 Tom Lane wrote: > "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. Agreed, updated: |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 password creation/changes to the server in plain-text, not MD5. -- 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: Magnus Hagander on 20 Oct 2009 03:11 2009/10/19 Tom Lane <tgl(a)sss.pgh.pa.us>: > 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. The big difference is that you need to be superuser to change the name of a user, but not to change your own password. I know for example the Windows password policy thing has the same issue - if you rename the user, it doesn't have the password around to check, but you are an administrator so that's considered ok. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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: Tom Lane on 20 Oct 2009 09:42 Magnus Hagander <magnus(a)hagander.net> writes: > 2009/10/19 Tom Lane <tgl(a)sss.pgh.pa.us>: >> 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. > The big difference is that you need to be superuser to change the name > of a user, but not to change your own password. True, but the superuser doesn't necessarily know what the user has set his password to. 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: Robert Haas on 20 Oct 2009 10:07 On Tue, Oct 20, 2009 at 9:42 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Magnus Hagander <magnus(a)hagander.net> writes: >> 2009/10/19 Tom Lane <tgl(a)sss.pgh.pa.us>: >>> 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. > >> The big difference is that you need to be superuser to change the name >> of a user, but not to change your own password. > > True, but the superuser doesn't necessarily know what the user has > set his password to. Yeah, but I'm not sure this case is worth worrying about. People who actually care password security are likely to have checks that are substantially stronger than "!= username". ....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: Itagaki Takahiro on 15 Nov 2009 23:24
"Albe Laurenz" <laurenz.albe(a)wien.gv.at> wrote: > I wrote: > > Following the discussions in > > http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php > > and > > http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php , > > here are patches for > > > > a) a hook in backend/commands/user.c that allows one to add > > password checking functions > > b) a contrib module that makes use of the hook and > > c) documentation for the contrib module. > > I found a small but embarrassing bug - here is another version. I've reviewed your patch. The rough approach looks fine, but I have some comments about function declarations and coding style. The hook in core is declared as: typedef int(*check_password_hook_type)(char * const username, char * const password); but result type is actually treated as a boolean. So, it also should declared as bool. Also, the type of arguments should be "const char *". There several comments in contrib/passwordcheck. - We don't need #ifdef PG_MODULE_MAGIC because the module works only on 8.5 or later; PG_MODULE_MAGIC is always defined there. - _PG_fini() is never called in HEAD anymore. Please remove it. - The function declaration of _PG_init() should be _PG_init(void). - isalpha() should be called as isalpha((unsigned char) c) because it could be crashed by multi-byte characters. - "8 characters long" would be better if it is configurable easily. I don't think it is to be a GUC varable, but #define should be used. - The logic in "check if the password contains only letters" should be "check if the password contains both upper-case, lower-case and non-alphabet letters". Passwords like "12345678' are not enough. - Coding style should more follow postgres. For example, posisions of '{', usage of spaces and linebreaks. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |