On Tue, 5 Dec 2006, Andrew Dunstan wrote:
> > 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.
I agree with what they should do. However, what usually happens is that a
senior employee wants to plug their tool (reporting, or what ever) into
the database. Because we aren't supported like, say, Oracle is they have
to connect via ODBC. What seems to happen then is, they're given a
username and password. It's those accounts you have to worry about.
> > 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.
Right, I think PAM does a great job but it isn't available on, say,
Windows.
Thanks,
Gavin