On 10/14/2009 06:02 PM, Dave Page wrote:
On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
<kevin.gritt...@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<m...@mielke.cc>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
