Re: Weak passwords and brute force attacks
От | Gavin Sherry |
---|---|
Тема | Re: Weak passwords and brute force attacks |
Дата | |
Msg-id | Pine.LNX.4.58.0612081312320.28992@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: Weak passwords and brute force attacks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Weak passwords and brute force attacks
|
Список | pgsql-hackers |
On Tue, 5 Dec 2006, Tom Lane wrote: > 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. I'm not sure what's commonly done but I read it on some slides about PAM. I looked at what PAM does just now. It does do something close to what I did -- but with more configuration capabilities -- and checks for palindromes and similarity when changing a password. > > > 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. I figured it might be useful for applications like pgadmin which wanted to send the password encrypted on the wire but wanted to test of its strength. > > 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. > That doesn't seem to be what PAM does, at leasts in the default config. What they do do is to sleep for a random period between no sleep and the threshold, so that the attacker cannot guess the appropriate time to wait before hanging up. Thanks, Gavin
В списке pgsql-hackers по дате отправления: