Rejecting weak passwords
in [PgSql]
|
From: Tom Lane on 28 Sep 2009 14:37 Marko Kreen <markokr(a)gmail.com> writes: > So promoting the ENCRYPTED 'foo' as "secure" may lure users into > false sense of security, and be lax against sniffing and logfile > protection. This argument is entirely irrelevant to the point. Yes, ENCRYPTED doesn't fix everything, but it is still good practice to use it and most well-written tools will. So having a weak-password detector that can only work on non-encrypted passwords is going to not be very helpful. > IOW, having plaintext password in CREATE/ALTER time which can > then checked for weaknesses is better that MD5 password, which > actually does not increase security. This is not acceptable and will not happen. 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. We're not going to give up protection for that in order to provide an option to do weak-password checking in a place that simply isn't the best place to do it anyway. 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 28 Sep 2009 14:40 On Mon, Sep 28, 2009 at 2:00 PM, Marko Kreen <markokr(a)gmail.com> wrote: > So promoting the ENCRYPTED 'foo' as "secure" may lure users into > false sense of security, and be lax against sniffing and logfile > protection. ENCRYPTED prevents the user's password from being stolen by a modified server. ....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: marcin mank on 28 Sep 2009 17:49 > 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. Maybe it is time to look at something like bcrypt. http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html Greetings Marcin -- 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: Josh Berkus on 28 Sep 2009 18:52 > 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. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.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: "Joshua D. Drake" on 28 Sep 2009 18:59
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)? Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |