Rejecting weak passwords
in [PgSql]
|
From: Magnus Hagander on 28 Sep 2009 09:34 2009/9/28 Stephen Frost <sfrost(a)snowman.net>: > * 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. That sounds like the one I thought about :-) -- 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: Andrew Dunstan on 28 Sep 2009 09:54 Ing. Marcos L. Ortíz Valmaseda wrote: >> >> My vote is for #3, if anything. >> >> > 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 > > I'm voting for #3 precisely so postgres doesn't have to think about it, and the module author will do all the work implementing whatever rules they want to enforce. 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: Magnus Hagander on 28 Sep 2009 10:24 2009/9/28 Andrew Dunstan <andrew(a)dunslane.net>: > > > Ing. Marcos L. Ortíz Valmaseda wrote: >>> >>> My vote is for #3, if anything. >>> >>> >> 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 >> >> > > I'm voting for #3 precisely so postgres doesn't have to think about it, and the module author will do all the work implementing whatever rules they want to enforce. That makes a lot of sense. Then we could perhaps ship a cracklib2 provider in contrib. -- 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 28 Sep 2009 10:46 Andrew Dunstan <andrew(a)dunslane.net> writes: > Albe Laurenz wrote: >> 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. Yeah. I think there is no chance of anything in this vein getting accepted into core Postgres, if only because everybody will have a different idea of what it needs to do. A hook function (no need for a GUC) would be a reasonable proposal. 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 28 Sep 2009 11:06
Actually there's a much bigger problem with asking the backend to reject weak passwords: what ya gonna do with a pre-MD5'd string? Which is exactly what the backend is going to always get, in a security-conscious environment. 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 |