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.Grittner@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@mielke.cc>