If a user (including the user 1) attempts 5 invalid logins, they are blocked for 6 hours. Requesting an email reset allows the user back in. But after a password reset, the flood block remains, so the next login, even after the password reset, the user is still blocked with the message "5 failed login attempts for this account. It is temporarily blocked."

Once a user resets the password successfully through email and changes the password, the flood block should be removed. It is not.

Comments

ilo’s picture

Version: 6.x-1.0 » 6.x-1.x-dev
Category: bug » feature

Actually, the number of attempts and the time the user is blocked (hard or soft) is configurable. The key is that (hard) blocked users can not login the site, because they are blocked accounts. That is the way it is for Drupal blocked users, and that is the way it should be. If you don't want your users to be hard blocked, then remove the option, because Drupal by default does not unlock users that reset their password.

I'm in favor of removing the (soft) block lock operation when a user resets its password, but what an infortunate situation if your users attempt 5 times even being warned about the account will be blocked, and then, once blocked, they try the password recovery process. And just to mention, password reset operation performs a login operation, so soft-blocked users will still be able to join the site by resetting their password (haven't tested).

Lets wait for others to see their thoughts. Thanks for the report.

squ1rr3l’s picture

Well I reported it because it caused confusion for some users and administrators.

Not sure what you are referencing by (hard) and (soft) blocks (sorry).

What I have encountered is users (yea, they do this) trying 5 times (seems reasonable for my purposes), then they figure out they just don't have the right password and get it reset. I don't think they are even reading the 'you will be blocked' warning (not that there's anything we can do about that).

Anyway, this gets really confusing for the admins when they get users reporting that they have reset their password, but are still block, and the admin looks at the user account, but it's active and not blocked, so they reply to the use "no, you're not blocked." Eventually they figure out what happened, but I do think in this case the (soft?) block should be reset.

Hopefully we are talking about the same thing.

ilo’s picture

Hard blocking and softblocking are two different ways of blocking users. The first one mimics a user blockage (disabling the full form submission process), and the second one actually blocks (set status = 0) the user.

If users will try 10 times before they realize that the account might be blocked if they persist, then the problem are the users. I mean, there is nothing bad in trying... and I'd say that if the account is not blocked, should they keep trying ad-eternum? or will they reach an attempt limit when they tried for the 25th time? I've to admit that up to now, I've never found this situation. If you have one or two issues about that, then consider giving more attempts, but soon or later they will give up and reset the password.

I'm in favour of give a better message on the Nth attempt with the link to 'Request new password', but that 'blocking' status should not be changed, or blocked users will find a way to get rid of their blocked status (security risk for other users?).

Administrators facing problems with this should read the configuration options and their meaning, and our work should be make sure the descriptions and default values would fit the most used case, not the worst case. Anyway, I'd like to hear more opinions, and for sure I'm open to change both (descriptions and default options) if there is some consensus or rationale for this change.

About messages or module's logic being confusing.. well, I can understand that the documentation would require more extended descriptions, and I'll accept them, but Drupal's block status is that way, and 'admins' should be used and understand that a blocked user is a blocked user, and by no means, changing the password once they have been blocked would remove that status (an admin should be able to review the site logs and verify that block operation ocurred before the password reset).

squ1rr3l, I'd like to know your opinion about the module documentation. Is not it clear enough that we are reaching this situation too often? Deekayen, what do you think? perhaps it requires more work.

ilo’s picture

Sorry, I forgot to mention, yes, soft block should be reseted with current module code afaik. Only the login form is protected, the password reset form is not, neither the OTP url or link. Anyway, this must be verified.

Thanks for sharing this concern, much appreciated.

squ1rr3l’s picture

Thanks for the explanation.

I agree with your points. In fact I think changing the attempt limit to 10 would probably virtually eliminate the issue.

As for the documentation: I actually failed to find any documentation. Probably just not looking in the right place.

I did find your "Login Security" module. Documentation there seems very clear to me. I don't actually have that module installed, though.

deekayen’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev

bumping version

rooby’s picture

malcomio’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)