Implemented Brute force login mitigation

[digitalpoint]

The XenForo_Model_Login::countLoginAttempts() is based on the username *and* IP combo. Might not be a bad idea to have a secondary check for login attempts made just from IP (and throw up the captcha mode if needed).

Long story short is someone got a database of emails/passwords from somewhere (not our database, because the vast majority of the emails attempted were never in our system). But they were trying around 500 emails per second for about 24 hours before I noticed an awful lot of old users were logging in out of the blue and doing nothing. They ended up successfully logging into 1,458 accounts (wherever they got that email/password database, it must have been huge).

For now, I wrote a script to reset all those user's passwords automatically and also changed the XenForo_Model_Login::countLoginAttempts() method to be based on IP address (not username/email), and made it based on the last hour of login attempts. Also made the cleanUpLoginAttempts() method based on an hour (of course).

Not a huge deal since we've handled it on our end already, but might be something to think about in the future to prevent brute force login attempts that span more than a single username/email.

 

[Alpha1]

Account security is getting more and more of an issue for communities. It would be good if XenForo would beef up security standards.

 

[Gladius]

Do we even need to like dp's suggestions?

 

[TickTackk]

There is also another of trying to do a brute force and was created by me (it is used by script kiddies these days to get access to XenForo resources lol), I reported to @Mike few months back but didn't get any response.

 

[Brent W]

It is unsettling to know that that many accounts were compromised.

 

[digitalpoint]

It is unsettling to know that that many accounts were compromised.

I know... the emails they were trying were getting a hit rate of about 1 in 1,000... And then of those, they tried once for whatever password they have. Really makes me wonder where they got the database of emails and passwords to begin with.

 

[Gladius]

There have been a number of known user data breaches over the last few years and many (most?) people tend to use the same logins with multiple sites... if somebody's aggregating and cross-referencing the data from all those exploits, they certainly have a huge database on their hands.

 

[Brent W]

I know... the emails they were trying were getting a hit rate of about 1 in 1,000... And then of those, they tried once for whatever password they have. Really makes me wonder where they got the database of emails and passwords to begin with.

vBulletin had their database hacked. I'd bet a lot of those emails and passwords would match up.

 

[Mike]

The original hesitation here had to do with an IP not necessarily representing a single person. As a clear case, consider an office of people behind NAT. However, that is clearly an edge case and things have changed in 5 years.

I have now changed our log in rate limiting code to have behaviors for both IP-user combos and IPs only, along with limits applied to 2 time periods. IP-user limits to 4 attempts in a 5 minute window or 8 in a 30 minute window; IP only checks double these. This will be in the next 1.4 release.

Clearly this doesn't entirely prevent the issue and there are different approaches that can be taken so we may re-evaluate if necessary.