Re: Weak passwords and brute force attacks
От | Tom Lane |
---|---|
Тема | Re: Weak passwords and brute force attacks |
Дата | |
Msg-id | 5684.1165336360@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Weak passwords and brute force attacks (Gavin Sherry <swm@linuxworld.com.au>) |
Ответы |
Re: Weak passwords and brute force attacks
Re: Weak passwords and brute force attacks |
Список | pgsql-hackers |
Gavin Sherry <swm@linuxworld.com.au> writes: > .... 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. Where did you get this design for a password strength checker? It doesn't sound like it has much to do with the algorithms commonly used for such things. > 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. As already noted, that seems approximately useless. > 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. This is a waste of effort, unless you propose to put the delay into both the success and failure paths, which hardly seems acceptable. Otherwise a guesser need only abandon the connection attempt after X microseconds and try another password. regards, tom lane
В списке pgsql-hackers по дате отправления: