What I’m trying to do:
A not so happy customer just called that he can no longer login to the application.
After some digging we found that he had previously entered the password wrong 10 times, which automatically blocks subsequent logins.
And to my shock we found some (lost) users that had the number 10 in this column
What I’ve tried and what’s not working:
Is this hardcoded into the system or is is possible to set this number?
Is this number automatically beeing reset afert some time or should we implement on our own?
To the best of my knowledge! There is not much documentation about this and no obvious way to handle this. Which seems quite dangerous for a mechanism that can potentially block users. Not trying to blame anyone but myself for this incident though!
Anyway we are thinking about a scheduled task that resets this column as well as user feedback for that case.
How do you guys handle this?
Or are we the only ones with forgetful users?
Greetings,
Mark
EDIT:
This behavior is in fact documented but obviously not very thoroughly read by my part:
Seems like the more secure way to handle this is to catch the TooManyPasswordFailures exception, and direct users to reset their password. Granted, allowing 10 tries every hour (or however frequently you run the scheduled task) isn’t going to give the brute force folks much of an advantage, but as a user I’d rather not have the time delay.
Also, thanks for pointing this out! This feature went in sometime in the last year, and I need to update my apps to handle that exception and give the users notice about what’s happening.
The issue I see is that they are never reseted. Which would mean that if you type in a wrong password once per week this will eventually occur in the 10th week after one wrong password.
Which is, at least for me, the case I am worried about the most.
But agreed catching the exception will definetly be in our next release!
Yeah, that seems like a bug. A successful login should reset the field.
Edit: I’m seeing the field reset on a successful login.
Also, the default login form that Anvil provides does give a message about needing to reset their password because of too many unsuccessful logins. I could see users maybe ignoring the message, but it is there.
@mark.breuss Can you confirm that the n_password_failures column is not resetting after a successful login?
The documentation on the TooManyPasswordFailures exception is a bit lacking and clearly too easy to miss. I’ll add it to our list to have more information and to add an example in code of catching the exception.
In my users table I have all zeros, and I’m sure some (many (including me)) have typed the wrong password at least a few times, so my guess is that they are reset.
sorry for the late response, I did some more testing and I must apologize for the wrong bug report.
It seems as if a successfull login does reset the password.
Looking closer to the user table we found that those users that looked like they were not reseted created another account. -Thus the confusion on our end.
