Rejecting weak passwords
in [PgSql]
|
From: Magnus Hagander on 28 Sep 2009 06:11 On 28 sep 2009, at 11.54, "Albe Laurenz" <laurenz.albe(a)wien.gv.at> wrote: > Dear hackers, > > I have been thinking about ways to have PostgreSQL reject > weak passwords. > > I think the standard recommendation is "use PAM and LDAP", > but that requires the user to change the password outside > of PostgreSQL. And who would want to setup and maintain an > LDAP server just for this? > > Since everybody has different ideas what is a good password, > there should be some way to configure that. I've looked at > how Oracle does it, and they simply let you write a > stored procedure that throws an exception if it doesn't > like the password. > Since users are on cluster level and functions live in > databases, that won't work in PostgreSQL. > > I have come up with an idea or two and like to hear your > opinion. > > 1) One could have a set of GUCs like min_password_length, > min_password_nonchars and similar that everybody > could configure. This is not extremely flexible though. > 2) Another idea would be a GUC that contains a regular > expression that a password may *not* match. > Perhaps that's too limiting too. > 3) I have also considered a GUC that points to a loadable > module that performs the password check if set. > > Are there better ways? Isn't there some library we can link with and (conditionally) use? I believe windows exposes api function(s) to let you verify password complexity - I'm sure there is something similar available on unix, hopefully included on most common platforms? /Magnus -- 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 28 Sep 2009 07:35 Albe Laurenz wrote: > Dear hackers, > > I have been thinking about ways to have PostgreSQL reject > weak passwords. > > I think the standard recommendation is "use PAM and LDAP", > but that requires the user to change the password outside > of PostgreSQL. And who would want to setup and maintain an > LDAP server just for this? > > Since everybody has different ideas what is a good password, > there should be some way to configure that. I've looked at > how Oracle does it, and they simply let you write a > stored procedure that throws an exception if it doesn't > like the password. > Since users are on cluster level and functions live in > databases, that won't work in PostgreSQL. > > I have come up with an idea or two and like to hear your > opinion. > > 1) One could have a set of GUCs like min_password_length, > min_password_nonchars and similar that everybody > could configure. This is not extremely flexible though. > 2) Another idea would be a GUC that contains a regular > expression that a password may *not* match. > Perhaps that's too limiting too. > 3) I have also considered a GUC that points to a loadable > module that performs the password check if set. > > > My vote is for #3, if anything. 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: =?UTF-8?B?IkluZy4gTWFyY29zIEwuIE9ydMOtwq16IFZhbG1hc2VkYSI=?= on 28 Sep 2009 09:18 Andrew Dunstan escribió: > > > Albe Laurenz wrote: >> Dear hackers, >> >> I have been thinking about ways to have PostgreSQL reject >> weak passwords. >> >> I think the standard recommendation is "use PAM and LDAP", >> but that requires the user to change the password outside >> of PostgreSQL. And who would want to setup and maintain an >> LDAP server just for this? >> >> Since everybody has different ideas what is a good password, >> there should be some way to configure that. I've looked at >> how Oracle does it, and they simply let you write a >> stored procedure that throws an exception if it doesn't >> like the password. >> Since users are on cluster level and functions live in >> databases, that won't work in PostgreSQL. >> >> I have come up with an idea or two and like to hear your >> opinion. >> >> 1) One could have a set of GUCs like min_password_length, >> min_password_nonchars and similar that everybody >> could configure. This is not extremely flexible though. >> 2) Another idea would be a GUC that contains a regular >> expression that a password may *not* match. >> Perhaps that's too limiting too. >> 3) I have also considered a GUC that points to a loadable >> module that performs the password check if set. >> >> >> > > My vote is for #3, if anything. > > cheers > > andrew > You have to analyze all points before to do this. I vote too for the third option, but you have to be clear that how do you ´ll check the weakness of the password: 1- For example: the length should be greater that 6 char.. 2- The password should be have a combination fo numbers, letters and others dots Things like that you have to think very well, or to do a question to the list asking which are the best options. I think the same about the PAM and LDAP auth Regards -- "DBAs must implements decisions based on the best fit of the application,DBMS, and platform ......for that reason.......I use PostgreSQL + Linux" Ing. Marcos L. Ortiz Valmaseda Línea Soporte y Despliegue Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD) Linux User # 418229 PostgreSQL User http://www.postgresql.org http://www.planetpostgresql.org/ http://www.postgresql-es.org/
From: Stephen Frost on 28 Sep 2009 09:16 * Magnus Hagander (magnus(a)hagander.net) wrote: >> Are there better ways? > > Isn't there some library we can link with and (conditionally) use? I > believe windows exposes api function(s) to let you verify password > complexity - I'm sure there is something similar available on unix, > hopefully included on most common platforms? cracklib2. Stephen
From: Bill Moran on 28 Sep 2009 09:24
In response to "Ing. Marcos L. Ortíz Valmaseda" <mlortiz(a)uci.cu>: > Andrew Dunstan escribió: > > > > Albe Laurenz wrote: > >> Dear hackers, > >> > >> I have been thinking about ways to have PostgreSQL reject > >> weak passwords. > >> > >> I think the standard recommendation is "use PAM and LDAP", > >> but that requires the user to change the password outside > >> of PostgreSQL. And who would want to setup and maintain an > >> LDAP server just for this? An option here is to have a way for PG to hook in to LDAP/PAM so that an ALTER ROLE actually changes the LDAP/PAM password. > >> Since everybody has different ideas what is a good password, > >> there should be some way to configure that. I've looked at > >> how Oracle does it, and they simply let you write a > >> stored procedure that throws an exception if it doesn't > >> like the password. [snip] > >> 3) I have also considered a GUC that points to a loadable > >> module that performs the password check if set. > > > You have to analyze all points before to do this. I vote too for the > third option, but you have to be clear that how do you ´ll check the > weakness of the password: > 1- For example: the length should be greater that 6 char.. > 2- The password should be have a combination fo numbers, letters and > others dots I think you've missed the point. If a loadable module is used, then it can do anything the DBAs need it to. You can write your own module if you're not happy with those provided. At that point, arguing about what makes a good password is pretty irrelevant. Note the paragraph that I didn't snip where Albe points this out. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |