[wp-hackers] Limit Login Attempts

[Chris Williams]

See below:

On 4/16/13 4:38 PM, "Vid Luther" <vid at zippykid.com> wrote:

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

I have no idea what this has to do with this discussion.  I'm only talking
about FAILED login attempts.

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

I'm not, nor have I ever, advocated locking people out by the username
they attempt to log into.  I don't know how/where that got in this
discussion.

Let me be clear.  I'm not advocating a core change anymore.  I'm
advocating that Automattic allocate its vast resources towards a solution
of the problem of brute force login attempts.  And exposing that solution
via a plugin.  Just like they did against the spam problem years ago.

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

Again, I'm not sure you're understanding.  I'm advocating a system where
the plugin, upon submission of a login form, checks it against an
Automattic database.  If it comes back bad (e.g., this IP has made 25 bad
login attempts in the last 24 hours), it denies the login regardless of
the validity of the username/password pair.  If it comes back good, and
the local host determines that login is invalid, it submits that failure
to the database.  That's it.  Probably the same or even less overhead that
either side sees in the submission of a comment for analysis today.

Surely the number of logins to all WP sites cannot be anywhere near the
number of spam comments submitted to Akismet.  Even if it were, this
problem (unauthorized access to WP sites) is at least as much of a threat
to the health of the WP community as the spam problem was -- before
Automattic essentially solved it.