Rejecting weak passwords
in [PgSql]
|
From: Tom Lane on 14 Oct 2009 11:11 Dave Page <dpage(a)pgadmin.org> writes: > I would suggest that in addition to the proposed plugin, we add an > suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED > PASSWORD to ensure that the password complexity can be checked when > roles are created or modified. That's going to stop us from being beat up? A GUC that forcibly *weakens* security? I can't see it. If you're really intent on making that happen, you can have your password checker plugin reject crypted passwords; we don't need such a questionable rule in core. 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: Andrew Dunstan on 14 Oct 2009 11:22 Tom Lane wrote: > Dave Page <dpage(a)pgadmin.org> writes: > >> I would suggest that in addition to the proposed plugin, we add an >> suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED >> PASSWORD to ensure that the password complexity can be checked when >> roles are created or modified. >> > > That's going to stop us from being beat up? A GUC that forcibly > *weakens* security? I can't see it. > > If you're really intent on making that happen, you can have your > password checker plugin reject crypted passwords; we don't need > such a questionable rule in core. > > > And you could have the plugin do that depending on a custom GUC. 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: Dave Page on 14 Oct 2009 11:25 On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Dave Page <dpage(a)pgadmin.org> writes: >> I would suggest that in addition to the proposed plugin, we add an >> suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED >> PASSWORD to ensure that the password complexity can be checked when >> roles are created or modified. > > That's going to stop us from being beat up? A GUC that forcibly > *weakens* security? I can't see it. If the communications channel uses SSL, and passwords are prevented from hitting the logs then (assuming there are no other weaknesses I haven't thought of), then the net effect would surely be tighter overall security? In a very security-conscious shop, the DBA won't have access to the underlying system at all, so debugging tools etc would be out of the question. In most shops, he will have access and can already just set the auth method to 'password' and then break out the debugger (or even replace the executables), so I can't see that this option would open up any obvious new attack vectors. Users are almost always the biggest weak-point in any security system, so should naturally be the first hole we look at plugging, before the ones that are much harder to exploit effectively - especially when those are only open to exploit by people who already have superuser privileges! > If you're really intent on making that happen, you can have your > password checker plugin reject crypted passwords; we don't need > such a questionable rule in core. Client software would need to have a standard way to know when to use ENCRYPTED PASSWORD or not. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.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: Marko Kreen on 14 Oct 2009 11:32 On 10/14/09, Dave Page <dpage(a)pgadmin.org> wrote: > On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > >> 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. > > > This is an area in which we often get beaten up in in technical > evaluations against other DBMSs. Password complexity checks are pretty > much standard features in other products and it hurts our adoption not > to be able to offer them, especially in large shops where the first > phase of the eval may be a simple box-checking exercise. > > I would suggest that in addition to the proposed plugin, we add an > suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED > PASSWORD to ensure that the password complexity can be checked when > roles are created or modified. Checking 1M common weak combinations against the md5 hashed password will take < 1s. You cannot count the commas in password, but thats it. The usual problems: 'username', '1234' can be still detected. > This would allow us to remain secure-by-default, and yet offer an > important option for many potential users. -- marko -- 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 14 Oct 2009 11:30
Dave Page <dpage(a)pgadmin.org> writes: > On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> If you're really intent on making that happen, you can have your >> password checker plugin reject crypted passwords; we don't need >> such a questionable rule in core. > Client software would need to have a standard way to know when to use > ENCRYPTED PASSWORD or not. Oh, so you want us to propagate extra support for this blatant security reduction all over the system too? No thank you. This whole line of discussion just proves the point that was made originally: it would be a lot better to do whatever checking you want done on the client side, rather than risk transmitting unencrypted passwords. If you are going to imagine that client-side software knows about such a GUC, you might as well imagine that they have cracklib built in. 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 |