[wp-hackers] Limit Login Attempts

[Vid Luther]

I'm glad we're discussing this, as Nacin said rushing to implementations is
a bad idea.


On Tue, Apr 16, 2013 at 6: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.
>
>
One thing I've realized is that it's unreasonable to think everyone has the
same definition of "reasonable" as me. All the hosters on the list can fill
days of WTF moments.  You also need to think about things like Roboforms
that some customers use on their own sites, for a valid purpose. Then the
"autofill/submit" feature of a lot of "password keepers"..

On a more practical note, doing something like this will require core to
put in a "state machine" for users, which is not trivial, plus you/we need
to think about how to support it. A user can be "disabled" for many
reasons, and what are the different states a user can have?

Then we get into the "authenticated v authorized" debate.. which is another
can of worms that we're not addressing right now.



> >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.  The number of failed login attempts has to be a minute fraction of
> the number of spam comments it filters today quite handily.
>

The resources are allocated for spam, not to log activity like this. We've
had our databases grow with people using activity tracker plugins and
seeing individual sites add 100k rows per attempted user. While we've built
our systems to handle surges, we didn't and shouldn't build our systems to
handle relatively useless data like this. We have logs at the edge, there's
no need to store this info on a per site basis.

We shouldn't assume everyone has the same resources as Automattic. Core
functionality that logs login attempts sitting on a small cloud server is
going to destroy that server in about 3-4 seconds of an attack like this
weekend.


>
> >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.


I think that's why the discussion is ongoing, I agree with you on
principle, if I want "password" as my password, it's nobody's business but
mine. The fact that, a warning and a rope to hang yourself with may be a
good idea here.