Re: Rejecting weak passwords

On 10/14/2009 06:02 PM, Dave Page wrote:
> On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)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(at)mielke(dot)cc>