Re: Weak passwords and brute force attacks

Gavin Sherry wrote:
> Hi all,
>
> Host-based authentication and the other security mechanisms we have at the
> moment provide fairly rigorous security but it seems to me there are two
> mechanisms other authentication systems provide which we do not: testing
> of the strength of passwords and delaying response after an authentication
> failure.
>
>

Frankly, if we're going to build this stuff in we need to expose the API
for password checking at least. Many apps run as a given postgres user
and set up application users and passwords as application level artifacts.

> The password strength test is pretty self-explanatory: DBAs often have to
> hand out accounts to a range of real people who will be using anything
> from reporting apps to testing new applications etc. With strength
> testing, a DBA can at least ensure that a certain standard of complexity
> is met. The attached patch adds two GUCs called 'test_weak_passwords' and
> 'min_password_length'. If 'test_weak_passwords', passwords will be
> analyzed during CREATE and ALTER ROLE. It's not as simple the password
> being greater than min_password_length. I guess the GUC name is a bit
> confusing in that respect. Instead, what we do is add up the different
> character types (lower, upper, digits, etc) and for each character type
> missing, we reduce the hypothetical password length: the theory being that
> the longer the password, the harder to guess.
>
> Now, in the presence of encrypted passwords being sent across the wire, we
> can't do anything. So, we export the password strength tester to libpq.
>

That assumes you trust the client. So then you are protecting against
stupidity, but not malice. But you are afraid that stupidity will open
the door to malice ...

> The second mechanism is the delay on authentication failure. The problem
> here is that a distributed application could attempt to brute force guess
> a password for a role. This could be fairly effective on a high speed LAN.
> So, the usual approach is to delay sending the failure message to the
> client for some period of time (specified in the patch by
> auth_failure_delay) to slow the progress of the password guesser.
> Naturally, environments where you cannot trust the local network sound
> like problem outside out scope. But, I see a lot of systems with sensitive
> company information (consider an HR system) which even employees should be
> denied access to.
>

Arguably such systems should not be using standard password auth at all.
SSL with client certs is probably the way to go. Relying on password
strength checking and delay in such a case would be, to use David
Fetter's recent phrase, putting lipstick on the md5 pig.

> Authentication failure delay can be done with PAM but not everyone will be
> abke to use PAM.
>

Well, pam_cracklib will do an outstanding job on all these issues for you.

I'm not opposed to providing some of this stuff, although some does seem
to be reinventing the wheel. But we should be careful about how much
security we think we are really providing.

cheers

andrew