Rejecting weak passwords
in [PgSql]
|
From: Jeff Davis on 28 Sep 2009 19:01 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. That doesn't solve the problem of an administrator brute-forcing your password. Regards, Jeff Davis -- 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 19:10 Jeff Davis 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. >> > > That doesn't solve the problem of an administrator brute-forcing your password. > > > > Indeed. These brute force checkers aren't checking them by actually trying the connection. 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: Tom Lane on 28 Sep 2009 19:19 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? 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 19:26 marcin mank <marcin.mank(a)gmail.com> writes: >> The case that ENCRYPTED >> protects against is database superusers finding out other users' >> original passwords, which is a security issue to the extent that those >> users have used the same/similar passwords for other systems. > I just want to note that md5 is not much of a protection against this > case these days. Take a look at this: > http://www.golubev.com/hashgpu.htm > It takes about 32 hours to brute force all passwords from [a-zA-Z0-9] > of up to 8 chars in length. Yeah, but that will find you a password that hashes to the same thing. Not necessarily the same password. It'll get you into the Postgres DB just fine, which you don't care about because you're already a superuser there. It won't necessarily get you into the assumed third-party systems. 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: "Albe Laurenz" on 29 Sep 2009 02:46
Tom Lane wrote: > > pgAdmin MD5's the passwords if you use the GUI to change them, or when > > add a user. It doesn't make any attempt to parse the SQL if you enter > > it yourself in the query tool though (nor is it going to). > > No, I wouldn't expect it to go that far. My point is just that > pre-MD5'd passwords are a lot commoner than Albe seems to think. Point taken. 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. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |