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

Tue Jul 21 16:00:48 BST 2020

Marlon,

On 21/07/2020 14:54, Marlon Deerr wrote:
>
> Jules,
>
> Awesome. Glad I was able to help.
>
> As for your explanation, it makes perfect sense now. If only everyone 
> in the world was really nice and had no knowledge of brute force attacks.
>
It's about the simplest possible form of "side channel" attack. You 
discover bits of information about the thing you are trying to break by 
watching it in some way. In this case, it's as simple as watching for 
when the error message would change. As I say, it's the simplest one.

Once you start having to be really careful, you suddenly realise you 
need things like a simple function that compares 2 strings (did their 
encryption key match the real one?), that *always* takes exactly the 
same length of time regardless of whether the strings match or not. 
Otherwise you're vulnerable to a time-based side-channel attack.

When you get into the world of chip+pin credit cards, you have be sure 
that whether the PIN matches or not, the *input* power required to run 
the chip doesn't change. Otherwise an ammeter (an electrical current 
probe) can watch and (very fast!) log the power consumption, and so you 
can make deductions about the internal decisions on the chip. Try lots 
of different input combinations and watch how the trace of current vs 
time is different for each input value you try.

There are literally thousands of examples, but they are a couple of the 
most common.
They rarely give you a direct answer or a direct way into hacking 
something, but they will provide more little nuggets of information that 
the hacker needs.

"Security by design" is fundamental. And extremely difficult!
But a very interesting subject. Try googling "side channel attack", I'm 
sure you'll find some interesting reading.

> With that said however, as for not showing the message to let the user 
> know that they have been locked out, is there a way for an email to be 
> sent to the administrator (maybe an option that can be turned on/off 
> by the admin) whenever someone’s account has been locked.
>
That's what the package "logwatch" is for. It's very good at it already, 
so I'm not going to reinvent it. :-)
Install and learn how to setup that.

Cheers,
Jules.

> This way if I am the admin, I am full aware of who’s account was 
> locked before they even generate a ticket to me. Receiving a 
> notification email of this can be a feature I choose to turn on or off 
> if I don’t want to be notified but will rather manually check logs on 
> my own schedule to see what’s happening on my ZendTo server.
>
>
> Marlon Deerr, Technology Manager
> 416-572-8795(direct) | MDeerr at hshlawyers.com 
> <mailto:MDeerr at hshlawyers.com>
> <https://www.hshlawyers.com>
> <https://www.linkedin.com/company/howie-sacks-&-henry-llp---personal-injury-law/> 
> <https://twitter.com/hshlawyers> 
> <https://www.facebook.com/HSHPersonalInjuryLawyers/> 
> <https://www.youtube.com/user/hshlawyers> 	3500 - 20 Queen St. W., 
> Toronto, ON M5H 3R3
> Fax: 416-361-0083 | Toll Free: 877-474-5997 | www.hshlawyers.com 
> <https://www.hshlawyers.com>
>
>
> This Howie Sacks & Henry e-mail is privileged, confidential and 
> subject to copyright. Any unauthorized use or disclosure is prohibited.
>
>
>
> *From:* Jules [mailto:Jules at Zend.To]
> *Sent:* Tuesday, July 21, 2020 9:43 AM
> *To:* ZendTo Users <zendto at zend.to>
> *Cc:* Marlon Deerr <MDeerr at hshlawyers.com>
> *Subject:* Re: [ZendTo] Failed to unlock user $user as did not match 
> usernameRegexp from preferences.php
>
> 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  <mailto:ZendTo at zend.to>
>
>     http://jul.es/mailman/listinfo/zendto  <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  <http://www.Zend.To>
> Twitter: @JulesFM

Jules

-- 
Julian Field MEng CEng CITP MBCS MIEEE MACM

'Think globally, act locally.' - Friends of the Earth

www.Zend.To
Twitter: @JulesFM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20200721/9a0a063a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagecae09c.JPG
Type: image/jpeg
Size: 125353 bytes
Desc: not available
URL: <http://jul.es/pipermail/zendto/attachments/20200721/9a0a063a/attachment-0005.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageb64590.JPG
Type: image/jpeg
Size: 7976 bytes
Desc: not available
URL: <http://jul.es/pipermail/zendto/attachments/20200721/9a0a063a/attachment-0006.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image0e8bb5.JPG
Type: image/jpeg
Size: 7843 bytes
Desc: not available
URL: <http://jul.es/pipermail/zendto/attachments/20200721/9a0a063a/attachment-0007.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image8ef134.JPG
Type: image/jpeg
Size: 7268 bytes
Desc: not available
URL: <http://jul.es/pipermail/zendto/attachments/20200721/9a0a063a/attachment-0008.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagec0f457.JPG
Type: image/jpeg
Size: 7059 bytes
Desc: not available
URL: <http://jul.es/pipermail/zendto/attachments/20200721/9a0a063a/attachment-0009.jpe>