Re: Rejecting weak passwords
mark@mark.mielke.cc
From: Mark Mielke <mark@mark.mielke.cc>
To: Dave Page <dpage@pgadmin.org>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, Marko Kreen <markokr@gmail.com>, Magnus Hagander <magnus@hagander.net>, Greg Stark <gsstark@mit.edu>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers <pgsql-hackers@postgresql.org>, mlortiz <mlortiz@uci.cu>, Albe Laurenz <laurenz.albe@wien.gv.at>
Date: 2009-10-15T16:23:31Z
Lists: pgsql-hackers
On 10/15/2009 03:54 AM, Dave Page wrote: > On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielke<mark@mark.mielke.cc> wrote: > >> On 10/14/2009 05:33 PM, Dave Page wrote: >> >>> No. Any checks at the client are worthless, as they can be bypassed by >>> 10 minutes worth of simple coding in any of a dozen or more languages. >>> >>> >> Why care? >> > Because many large (and small for that matter) organisations also have > security policies which mandate the enforcement of specific password > policies. Just because you think it's worthless to try to prevent > someone reusing a password, or using 'password' doesn't mean that > everyone else does. Some organisations will use such a feature in a > box-ticking exercise when evaluating, and others may actually decide > to use the feature, and expect it to work effectively. > > Beside, we are not in the habit of putting half-arsed features in > PostgreSQL. If we do something, we do it properly. > You miss my point (and conveniently cut it out). For users who accidentally break policy vs users who purposefully circumvent policy - the approaches must be different, and the risk management decision may be different. It's a lot easier to circumvent policy than most people (management specifically) realize. If your attempt it to absolutely prevent a determined competent individual from circumventing your policy - you need to do a LOT MORE than what you are suggesting. If you just want to prevent accidents - having the client software do the checks is fine. Cheers, mark -- Mark Mielke<mark@mielke.cc>