[wp-hackers] Limit Login Attempts

[Andrew Nacin]

On Tue, Apr 16, 2013 at 7:04 PM, Chris Williams <chris at clwill.com> wrote:

> This is only true if you limit based on a silly low number of attempts.
>  If you make it so that any IP that makes, say 25 (50?) failed login
> attempts (across all participating sites) is blocked from all
> participating sites, there is no reasonable way to say this is a "terrible
> user experience".  No one reasonably makes 25-50 attempts at their own
> account.
>

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.

>Anything we do might end up with huge database entries documenting failed
> >attempts. Any brute force activity can hog CPU and database resources,
> >lock
> >things up, and send things crashing.
>
> Clearly Automattic has the power/resources/bandwidth to be able to handle
> this.


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.

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.


> >There are a lot of ways for us to encourage (and even enforce) stronger
> >passwords. We should start there. If you have good ideas, check out:
> >http://core.trac.wordpress.org/ticket/21737. It's something a few of us
> >plan to prioritize for 3.7.
>
> Talk about "terrible user experience".  Force me to have a password with
> "at least one lower case, one capital, one digit, one symbol... Yadda ...
> Yadda."  UGH!  That's a terrible user experience.  If I WANT to have a
> crappy password, whose business is it but my own?  Warn me, maybe.  But
> enforce is the opposite of a good user experience.
>

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.

Nacin