Weak passwords and brute force attacks
От | Gavin Sherry |
---|---|
Тема | Weak passwords and brute force attacks |
Дата | |
Msg-id | Pine.LNX.4.58.0612060019060.29303@linuxworld.com.au обсуждение исходный текст |
Ответы |
Re: Weak passwords and brute force attacks
Re: Weak passwords and brute force attacks |
Список | pgsql-hackers |
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. 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. 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. Authentication failure delay can be done with PAM but not everyone will be abke to use PAM. Any thoughts on these ideas? Thanks, Gavin
В списке pgsql-hackers по дате отправления: