Rejecting weak passwords
in [PgSql]
|
From: Peter Eisentraut on 29 Sep 2009 07:43 On Mon, 2009-09-28 at 15:59 -0700, Joshua D. Drake wrote: > On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote: > > > It takes about 32 hours to brute force all passwords from [a-zA-Z0-9] > > > of up to 8 chars in length. > > > > That would be a reason to limit the number of failed connection attempts > > from a single source, then, rather than a reason to change the hash > > function. > > > > Hmmm, that would be a useful, easy (I think) security feature: add a GUC > > for failed_logins_allowed. > > Why a GUC, can't we just use ALTER ROLE (or ALTER DATABASE)? If you make it a GUC, you get those for free. (That's what the "U" means.) -- 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: Gurjeet Singh on 29 Sep 2009 09:07 On Tue, Sep 29, 2009 at 4:49 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Josh Berkus <josh(a)agliodbs.com> writes: > > Hmmm, that would be a useful, easy (I think) security feature: add a GUC > > for failed_logins_allowed. > > And the counts would be tracked and enforced where? > > Combining this with other suggestion: ..) Provide a GUC failed_logins_allowed ..) Add MAX FAILED LOGINS option to ADD/ALTER USER, which defaults to the GUC if not provided in the command. ..) Track per-user failed attempt counts in shared catalog, and reset on a successful login. Best regards, -- Lets call it Postgres EnterpriseDB http://www.enterprisedb.com gurjeet[.singh]@EnterpriseDB.com singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com Twitter: singh_gurjeet Skype: singh_gurjeet Mail sent from my BlackLaptop device
From: Tom Lane on 29 Sep 2009 09:48 "Albe Laurenz" <laurenz.albe(a)wien.gv.at> writes: > I thought about it some more, and I think that a password checking > hook might still be somewhat useful even for MD5-encrypted passwords; > the function could guess and exclude at least that dreadful > all-too-frequent case of username = password. True. You could probably even run through a moderate-size dictionary of weak passwords, depending on how long you're willing to make the user wait. (CHECK_FOR_INTERRUPTS inside the loop would be polite ;-)) 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 29 Sep 2009 10:18 On Tue, Sep 29, 2009 at 9:48 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > "Albe Laurenz" <laurenz.albe(a)wien.gv.at> writes: >> I thought about it some more, and I think that a password checking >> hook might still be somewhat useful even for MD5-encrypted passwords; >> the function could guess and exclude at least that dreadful >> all-too-frequent case of username = password. > > True. You could probably even run through a moderate-size dictionary > of weak passwords, depending on how long you're willing to make the > user wait. (CHECK_FOR_INTERRUPTS inside the loop would be polite ;-)) But how much value is there in that? This whole thing seems like a dead end to me. No matter how long you're willing to wait, putting the checking on the client side will let you far more validation for the same price. ....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: Andrew Dunstan on 29 Sep 2009 10:47
Robert Haas wrote: > On Tue, Sep 29, 2009 at 9:48 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >> "Albe Laurenz" <laurenz.albe(a)wien.gv.at> writes: >> >>> I thought about it some more, and I think that a password checking >>> hook might still be somewhat useful even for MD5-encrypted passwords; >>> the function could guess and exclude at least that dreadful >>> all-too-frequent case of username = password. >>> >> True. You could probably even run through a moderate-size dictionary >> of weak passwords, depending on how long you're willing to make the >> user wait. (CHECK_FOR_INTERRUPTS inside the loop would be polite ;-)) >> > > But how much value is there in that? This whole thing seems like a > dead end to me. No matter how long you're willing to wait, putting > the checking on the client side will let you far more validation for > the same price. > > > Why do we need to answer that question? If all we do is provide a hook, the cost is very low, and the decision on value is left to whoever is deploying some module to use the hook. And it will let people possibly implement some password security policy dictated by some PHB, and so check off a box on a form somewhere. Frankly, real security requires that you pretty much get out of the password game, but passwords will undoubtedly be around for a long time, since people will always trade security for convenience. 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 |