[ZendTo] Failed to unlock user $user as did not match usernameRegexp from preferences.php

[Jules]

Marlon,

You are doing a thorough job of this, thank you!

I have fixed the bug(s) you described. It now behaves exactly as 
expected, including the logging. This will be in the next release.

As for the feature request, the current behaviour is by design.
Someone nasty (a "bad actor" in the jargon) is using your ZendTo site to 
brute-force break your password.
They keep trying different passwords, but always get the same simple 
"incorrect" response.
They don't know ZendTo very well, and don't know your configuration 
settings at all.
As a result, they can't tell if or when they should give up trying to 
break your username/password, and try some other username instead.

As soon as you display *anything* different, the attacker knows the 
lock-out limit has been reached and so they should abandon their current 
attempt and try another one.

So you *never* give away any hints as to why the login attempt failed, 
beyond a simple fixed error message.

It logs it in the ZendTo log (/var/log/zendto/zendto.log is the file 
that the "System Log" button shows you the end of), so you can check there.

Cheers,
Jules.

P.S. The "start" and "expiry" date/time selectors on the "Request a 
drop-off" form are nearly there. I just want to tidy up that page design 
layout, it's a bit of a mess and I would prefer it to use a grid or two 
and a flex box like the "new drop-off" form now does.

On 21/07/2020 13:45, Marlon Deerr via ZendTo wrote:
>
> Hi Jules,
>
> I was testing ZendTo. I wanted to see what the log files will report 
> when a user is locked out after 10 unsuccessful login attempts. I 
> noticed that the log file (I think) is incorrectly reporting that a 
> user was not unlocked after administratively unlocking the account, 
> when in fact the user was successfully unlocked. Here are the steps I 
> performed.
>
> 1.Purposely attempted to log in as a user with incorrect password 10 times
>
> 2.Logged in as an admin user and examined the System Logs
>
> 3.System Log file successfully identified this locked user
>
> 4.Clicked on “Unlock User” from the main screen and selected the user 
> to unlock and unlocked her
>
> 5.Examined the System Logs again, but this time it said “*Failed to 
> unlock user $user as did not match usernameRegexp from preferences.php*”
>
> 6.Logged out as the administrator user
>
> 7.Tried logged in as this “supposedly” locked user *BUT* the login was 
> successful.
>
> Does this mean that the System Log file is incorrectly reporting that 
> the user was not unlocked, when in fact the user was unlocked?
>
> *ALSO:*Feature Request (if possible)
>
> When a user is approaching the maximum allowed failed login attempts 
> can you include a message that
>
> 1.Warns the user that you have x more attempts before you get locked 
> out (where x is a number)
>
> 2.After the user has failed to login after 10 attempts, instead of 
> just saying “Authentication Error. The username or password was 
> incorrect”, can it not say something like “Authentication Error. You 
> have attempted more than the allowed failed attempts to log in. Your 
> account therefore has been locked. Please contact your administrator 
> to have it unlocked”
>
> While testing this feature above, I found that I was not keeping track 
> of how many times I made a failed login and must have tried over and 
> over again waiting for a message to let me now that I was locked out. 
>  I think having such a message will help reduce IT Tickets from staff 
> wondering why they can’t log in. They may not even know they have been 
> locked out.
>
>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://jul.es/mailman/listinfo/zendto

Jules

-- 
Julian Field MEng CEng CITP MBCS MIEEE MACM

The current UK shipping forecast:
Trafalgar: Cyclonic 6 to gale 8 at first in southeast, otherwise northerly 5
to 7, becoming variable 3 or 4 in southeast. Moderate or rough, occasionally
very rough. Thundery showers. Good, occasionally poor.

www.Zend.To
Twitter: @JulesFM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20200721/4ce11b8e/attachment.html>