Rejecting weak passwords
in [PgSql]
|
From: Peter Eisentraut on 14 Oct 2009 18:24 On Wed, 2009-10-14 at 13:08 -0400, Tom Lane wrote: > The reason to not want cleartext passwords in the logs is that the > user doesn't trust the DBA. I originally implemented the encrypt-on-the-client logic because the previous way of using ALTER USER ... PASSWORD would promiscuously leave the clear-text password all over the place, including the psql history, where it accidentally pops up again when you scroll up, or possibly the pgAdmin log, and the server log where the DBA can't avoid reading it even if he doesn't really want to, from where it goes through PgFouine and onto a web server. While guarding against a DBA you don't trust is a side-effect of this, it should not really be a goal. Most password systems that I can think of pass the cleartext password into address space controlled by the administrator at some point. The goal should be to keep it there for as little as possible and not spread it around randomly. But users should know that the password they enter into any system can be seen by the administrator of the system. The canonical solution for a situation where you don't trust anyone is SSL client certificates. -- 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: Peter Eisentraut on 14 Oct 2009 18:25 On Wed, 2009-10-14 at 18:38 +0200, Magnus Hagander wrote: > So throwing out a wild idea that's probably just wild enough to even > consider, but one way to deal with the logging side of things would be > to deprecate/remove ALTER USER/CREATE USER with password, and add a > separate API call. With a separate wire protocol packet. That would > certainly take care of the logging part ;) I think that would be the correct fix. -- 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 18:28 Bruce Momjian <bruce(a)momjian.us> writes: > Tom Lane wrote: >> But the main point is to hide the cleartext password, in any case. > What if we added a GUC that only allowed password changes via an SSL > connection. How's that help? The user has already exposed their new choice of password to any hypothetical eavesdropper. Of course, if they're smart, they'll pick a different password before they try again on a secure connection ... but good luck hoping for that. (And, again, there is ABSOLUTELY NO NEED for us to put such debatable policies into the core. Anyone who thinks that's a good idea can have his password-check plugin enforce it.) 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: Mark Mielke on 14 Oct 2009 18:29 On 10/14/2009 06:02 PM, Dave Page wrote: > On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner > <Kevin.Grittner(a)wicourts.gov> wrote: > >> Well, sure, but we're talking about a client going out of their way to >> wrestle the point of the gun toward their own foot, aren't we? If >> we're worried about the user compromising their own password, we have >> bigger problems, like that slip of paper in their desk drawer with the >> password written on it. I mean, I know some of these checklists can >> be pretty brain-dead (I've been on both sides of the RFP process many >> times), but it would seem over the top to say that client-side >> password strength checks aren't OK for the reason you give. >> > See my previous comment about dates. Check-box items aside, I have > absolutely no desire to try to give the illusion of a security > feature, when in reality any user could easily bypass it. This is only true if you thing 'create/alter role ... password ...' is intended to be used by hand - and if you think this, are you not concerned that the password shows up on the screen as the user types this? It's not an illusion if the user requires effort to bypass it. Who are you protecting? If you are trying to protect the user from themselves - I'd start by disabling 'create/alter role ... password ...' altogether and requiring some other means of the user securely setting a password. At our company we have a single-sign on system where users must login to a central password server to change their password. The central password server provides the password strength test. The intent is for none of the applications to ever know or see the password. It's not about trust - it is about principle. The DBA and/or application has no need or requirement to know the password. They only need to know that it is valid. For web-based applications, the user authentication is accomplished via a forward to one of the central password authentication servers, which upon successful login, forwards the user back to their intended application with a token that proves they have authenticated. If you think security is such an important thing - why not go all the way? Disable the entry level security provided by PostgreSQL allowing SQL commands to 'set' a password entirely. Use a token-based system with a third party trusted authenticator. I'm not being facetious. I think it's silly to argue that 50% is insufficient, and that lots of effort should be spent on reaching 55%, when you are clearly nowhere near 100% in either case. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- 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: Mark Mielke on 14 Oct 2009 18:30
On 10/14/2009 06:25 PM, Peter Eisentraut wrote: > On Wed, 2009-10-14 at 18:38 +0200, Magnus Hagander wrote: > >> So throwing out a wild idea that's probably just wild enough to even >> consider, but one way to deal with the logging side of things would be >> to deprecate/remove ALTER USER/CREATE USER with password, and add a >> separate API call. With a separate wire protocol packet. That would >> certainly take care of the logging part ;) >> > I think that would be the correct fix. > Yep. +1. If we are really so paranoid. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |