Triggered lockouts sometimes not logged to Simple History

[TuringTux]

update_login_failed_count should, if I read this correctly, write a log message for the plugin Simple History whenever a lockout is put in place.

However, I was just unable to login on a website on a new computer (with a message informing me about a lockout in place) without there being any message in the Simple History logs (they only were about the global lock counter increased for attempts to log in using an account admin that does not exist).

Sadly, I currently don't have further details about this issue (other than having experienced it occasionally for several months in a row now). I am in the process of collecting more evidence, which I will upload here as soon as I find some :)

[figureone]

Can you remember if you were logging in with an email address instead of a username? I was reviewing the code and noticed that when we hook into the wp_login_failed hook, we only handle usernames and not email addresses.
https://developer.wordpress.org/reference/hooks/wp_login_failed/

[TuringTux]

Hey, thanks for the quick reply. No, I am fairly certain I used a username to log in (no 100% guarantee, though – I usually use a username so I think I did so that time as well, but I will pay attention to it next time)

[TuringTux]

I think I have found the problem here: My account (user id, let's say, 42) has a user name in the format of <lastName> (e.g. tux) and comes from LDAP. However, a few years ago the user names were all in the format <firstName>.<lastName> (e.g. turing.tux in my case).

The migration of user names worked pretty fine, but apparently, it left some rough edges: Authorizer still thought my login was turing.tux, meaning it stored a user counter that looked at only this particular username. Whenever I tried to log in with the new tux username, the global counter was considered.

If, like usual, some bot tried to brute-force the password imaginary admin account, that would affect the global counter as well. This means I would've always been locked out when the global counter indicated lockout.

This means there actually was a lockout message, namely the one

about the global lock counter increased for attempts to log in using an account admin that does not exist

How I reset the global counter

To quickly be able to login again, I reset the global counter:

update wp_options set option_value = 0 where option_name = 'auth_settings_advanced_lockouts_failed_attempts';

How I fixed the problem

update wp_users set user_login = 'tux' where user_login = 'turing.tux';

[figureone]

Thank you for investigating this one! I see what happened. Since the LDAP provider (by default) matches on the email address field, it still allowed you to log in with the tux username (which exists in LDAP), even though the WordPress username was still turing.tux, because the email address associated with both was the same. On a failed login, all Authorizer sees is a failed login for the nonexistent tux user.

This won't help your specific case, but we added a second lookup on email address before incrementing the failed login counter. This catches anyone failing a login attempt with an email address for an existing user (incrementing that user's counter instead of the global counter): 3d392fc

[TuringTux]

Thanks for adding the lookup!

Yeah, the specific case is indeed pretty niche. Well, maybe the updated log message on failed logins might help future admins with the same problem (when they wonder why no user with that name exists and they then go looking in the user's database table or list on the UI).

[figureone]

Just released version 3.7.0 with these and other fixes. Let us know if you run into any problems and as always thank you for your contributions!