[wp-hackers] Limit Login Attempts

[Chris Williams]

And of course "send" was pressed too soon...

>On 4/17/13 7:16 AM, "Andrew Nacin" <wp at andrewnacin.com> wrote:
>>So the issue here is it is unlikely for there to be a single IP that
>>makes
>>that many attempts (to a single site). More and more, these guys are
>>going
>>to use botnets and are going to carefully spread out their IPs. As Vid
>>points out, "reasonably" has a lot of nuance to it. You could have an
>>organization with a large WordPress install and 50 people accessing it,
>>and
>>all use the same IP behind a router. Now suddenly if everyone screws up
>>their password once that day, you have a problem.
>>
>>I'm not saying it couldn't help. It probably could. But it's an awful lot
>>of effort and setup time to *maybe* have some positive effect, and likely
>>to have known and unknown negative effects.

Under this nightmare scenario, the system administrator disables the
plugin and contacts Automattic for removal.


>>Sure, but individual servers don't. Imagine the number of HTTP requests a
>>server will still need to issue, not to mention the amount of data they
>>will need to store locally, if only temporarily. I don't speak for, or
>>work
>>at, Automattic, but I doubt they'd see this as a idea worth pursuing,
>>unless it was just one more thing that VaultPress (or Jetpack, or
>>Akismet)
>>took care of for you. But availability of local resources (during an
>>attack) and whether this would even make a difference makes me question
>>it.
>>This isn't something that should be primarily done at the PHP level. This
>>needs to be done higher up the stack.

For each time the login form's submit button is pressed you get one small
back and forth to Automattic.  And one more for each failed attempt.
That's hardly a big load


>>I do know that some folks at WordPress.com have been working on a lot of
>>password strengthening things over the last few months and that it was
>>written with the ability for it to be contributed back to core as early
>>as
>>3.7. So that's good.

>>Not sure if you read the ticket, but it isn't about a set of password
>>rules
>>like that. It was about detecting weak passwords from different angles -
>>names, birthdates, dictionary words, repeating numbers/letters,
>>insufficient length, etc. These aren't necessary enforcement rules,
>>either.
>>We'd make sure the user is aware we've noticed that they have a terrible,
>>no good password.
>>
>>No amount of global bot detection is going to solve the problem of the
>>user
>>with the dictionary password. They're gonna get hacked sooner or later.
>>And
>>neighborhood watch groups don't help when the bad guys can just walk up
>>to
>>a house and into an unlocked door.

I'm not trying to solve the idiot user.  You can't help them from
themselves.  I'm trying to kill this bot.