immediate lockout on password recovery

I tried to reproduce this and don’t have the same problem myself. On your Wordfence Options page, can you make sure ‘Alert when the “lost password” form is used for a valid user’ is enabled, if it isn’t already, and see if you also get 3 emails about the password resets?

Also, can you check on Wordfence’s Live Traffic page, to see if you see visits from various IP addresses? (You may need to disable caching if it is enabled, before turning on the Live Traffic option.) The password reset limiting is tied to IP addresses, and if there is an issue formatting network addresses on your host, that could be the issue.

If neither of these help, can you find the visits logged in your site’s access log, at the last time this issue happened? There may be a link scanning tool tied to their email (possibly antivirus software) or a browser extension that is pre-fetching the reset link to scan the page — you might be able to see that in the log. I’m not sure why it would try twice, but it might be a possibility.

Hi Matt!

Sorry for the delay in responding.

The ‘Alert when the “lost password” form is used for a valid user’ was already enabled, and I was definitely NOT getting three emails. ??

I have asked the client to collect IP addresses, and I’ll try to look at the Live Traffic &/or access logs if it happens again.

Meanwhile, the client is simply asking people specifically to use their email addresses rather than usernames, and this seems to solve the issue. What seems weird is that this solves the issue.

If the problem were that their browser or antivirus were pre-fetching, wouldn’t this also make using the email address cause them to get locked out?

I’m wondering if it’s something funky about the way Gravity Forms user registration is setting up their accounts– but it seems like that ought to be pretty straightforward…

Thanks for the reply. I’m looking at the difference between resets by email address and by username, and will send that on to the dev team. I tested again and found no difference in the lockouts happening by either method (I still got locked out on the third attempt), but I didn’t get the notice for resets using the username.

You’re right that any pre-fetching shouldn’t make a difference between users using an email address or username — I’m thinking if the the result was cached, it might not hit the pages after the first attempt, no matter which method. (This probably is not it anyway though, since the blocking occurs when the form is posted.)

For the users’ benefit, you might increase number of allowed forgotten-password attempts to 5 or 6. If you can get the access log that shows at least a couple of password resets, we can still see if multiple attempts appear right in a row for a single IP.

If you want, you could also temporarily set the “Amount of time a user is locked out” to the lowest setting, and try resetting your own password on the site — if you did get locked out on the first try, that would rule out user error. (You would be locked out for a few minutes of course. If you have a mobile device on a cell network, you could use that so that your regular IP wouldn’t be locked out.)

WFMattR, I tested by trying to reset my own password, and did not get locked out. So maybe there was some user error going on.

Another possibility is that something related to caching was interfering. Earlier today I ended up emptying all caches in trying to solve another issue on the site.

Meanwhile, the client is given out instructions to use email addresses, and so far we had no further reports of being locked out.

Ok, hopefully that was it, and user error was involved — it’s hard to believe that sometimes when two happen so close together, but it can happen. ?? It might also be that the mail server for the site was having trouble that day — I could see users clicking the password reset button a few times, if they don’t get their emails immediately.

If it might have been user error (or slow mail), increasing the allowed forgotten-password attempts may still be helpful for users who might be too impatient.

I’ll mark this topic “resolved” for now, but of course, re-open it if needed. If you do get a copy of the access log showing one of these, I’d be interested to take a look, too.

-Matt R

Hi WFMattR!

One of my team members got locked out and provided some helpful new info! ??

My team member typed his username into the pw recovery window (rich), but when I looked closely at the lockout in WF, it says that the user was immediately locked out for using an invalid username “kljfW39$;kj” (not the real password, but the 16 character password that was orginally generated by WP).

Something is taking the typed in username & transposing it into the assigned password.

My teammate reports he was using Chrome for Mac. I have been having all sorts of funky issues with Chrome in the last couple of weeks– despite using the newest versions. Maybe it’s a Chrome-related issue?

Wow, that is even more unusual! There shouldn’t be a way for the existing password to get into the password reset process, since there is only one field on the reset form, and its name is different from the regular login/password fields — so is it possible he was locked out by continuing to test, after trying to reset the password? The only other possibility I can think of is that if the users are saving passwords in Chrome, that Chrome is putting them in the wrong field — that would be a pretty bad bug!

I’ve heard of a few other Chrome issues myself lately, but I don’t know of any dealing with form fields yet.

Otherwise, do any of the plugins that you’re using affect the login process? If you have a development copy of the site with all the same settings and plugins (or if the site has off-peak hours where regular users are unlikely to be on), you could test deactivating other plugins that may be involved, and see if the same problems happen — that might be a little tough too, since you’ll need at least two people, so one can unlock the other.

Let me know if any other clues come up, or if you get a copy of the access log to look at — an IP or date and time should be enough to see the timing and number of attempts that the server is seeing.

-Matt R