[wp-hackers] Limit Login Attempts

[Chip Bennett]

IMHO it would be best, at this stage of such discussions, to dissociate the
proposed solution from any given entity who might implement it. Automattic
is a commercial endeavor independent from the WordPress project, and may or
may not want to take on the effort/burden of implementing a SaaS solution
to the brute-force attack problem. It is somewhat presumptuous to discuss a
solution provided by Automattic unless/until Automattic themselves indicate
a desire to develop such a service.

Also: Automattic has commercialized Akismet. While that's certainly within
their prerogative, it likely does not bode well for a critical security
solution. While several other anti-spam tools exist for WordPress users, it
is unlikely that the same will hold true for a solution such as the one
being discussed here.


On Wed, Apr 17, 2013 at 10:40 AM, Chris Williams <chris at clwill.com> wrote:

> 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.
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>