LoginUserLocks - Security Fix [Paid] [Deleted]

[tenants]

oh wait... you have a library inside your library.. that's causing me confusion

Delete LoginUserLocks_v1_0_1 from site folders and add the folder LoginUserLocks to your library

You possibly extracted the zip as "Extract to LoginUserLocks_v1_0_1", this means the LoginUserLocks is inside another folder named "LoginUserLocks_v1_0_1"

So, drag the folder named LoginUserLock into your library

Having that library folder inside a folder named library is going to confuse things
but your final file path should look like this:

yourforum/library/LoginUserLocks/
and inside that add the xml file, so that you have the path
library/LoginUserLocks/addon-LoginUserLocks.xml

 

[Divinum Fiat]

Someone is merciful! Yay, it worked! Thank you!

So the only area for me to do anything is in the acp/option area? There are only two values I can change, correct? Are the default settings okay?

 

[tenants]

Yay, that's good news.


Just for the future, almost all plugins have the structure

yourforum/library/X/addon-X.xml

Where X is the add-on name (but you can add the XML just about anywhere, as long as you point to the correct path when installing)


It's been a while since I looked at this (once installed, you don't need to worry about it ever again)

But it's a simple add on to prevent brute force attempts from the forum login area, the default values are reasonable, this is what I use:




And they are the only things that you need to change (if you want to), but yes the default values are good to use

 

[tenants]

You can then test it if you want, by trying to log in that many times within the time set
(in my example, I would need to try to do this 8 times within 80 seconds before I see the message)

 

[Divinum Fiat]

Thank you so much for all your help!

 

[Divinum Fiat]

Okay, this is really embarrassing! With the ordeal of the infamous other thread and the rebuild of the backup, I lost this entire install and the work you did (setting manual approval to 'reject'). I retraced the steps and uploaded the add-on again and it worked fine. It's there in the add-on list, activated and all. But when I go to 'tools' it's nowhere to be found. Why could this be?

 

[tenants]

ACP >> Tools is usually where you find Logs and systems tools (rebuilding caches / cron jobs / system health check)

There is nothing in tools for this plugin. It's a simple plugin for user locks (it solves a security issue, and I've kept it simple)

But there are some options (just a couple) as shown in the image above.
The options for this plugin are found in the ACP >> Home >> Options >> LoginUserLocks

​

 

[Divinum Fiat]

oh cool, got it! Thanks so much. ;-)

 

[MattW]

I'm now running this on my site

 

[MattW]

If the user has CAPTCHA in place, after 5 attempts the CAPTCHA is activated. However, this is of no use, and does not prevent multiple requests from continuing (see norecaptcha / recaptchaocr / captchasniper / AutoCaptcha / deathbycaptcha / Stiltwalker / Custom OCR / ANNs)

^^^Doesn't the new key keyCaptcha pretty much make this statement not apply to it?

I'm running KeyCaptcha on my site, and I can't actually get the user lock to kick in, even when I complete the captcha image? I set it to 5 attempts and to lock me out for 60 seconds while testing. 5 attempts goes by, captcha is activated, but it never locks out.

EDIT: Disabled KeyCaptcha, and the lock out works.

Scratch all that, I wasn't completing the picture quick enough. Just tested again, and it does work with KeyCaptcha.

 

[tenants]

Scratch all that, I wasn't completing the picture quick enough. Just tested again, and it does work with KeyCaptcha.

You have to complete all X attempts within y seconds.
5 attempts within 60 seconds is just about do able for humans when completing CAPTCHA (I would test it with 120 seconds just to make sure it pops up and then set it back to 60) .Things like locks often don't really need to be seen by humans under normal user cases, it's automation that we are really trying to prevent. The ACP area has a lock of 15 minutes after 5 attempts (in my opinion, this is probably over kill).

Automation would expect to fire thousands of attempts every seconds (so would get a lock within less than a second). A lock of 60 seconds is more than enough to slow it down to a point that it is as good as usless.

^^^Doesn't the new key keyCaptcha pretty much make this statement not apply to it?

I haven't seen keyCaptcha being bypassed with automation yet (that doesn't mean that it can't be / can be)

It has been targeted once by XRumer (a few builds ago), but doesn't currently get passed it. But we're not talking about spam bots, brute force applications are often home made solutions

User locks are more important for scenarios where
i) There is no CAPTCHA > ii) The is only QA > iii) The user is using CAPTCHA that can easily be bypassed (reCAPTCHA + others)

 

[Parsnip]

Is there any way for the admin to be notified of failed login attempts, either by email or displaying in a log file?

 

[tenants]

Not right now, I could add a log information

What level of information do you think should be in the logs

Each time the user fails a log in :

.. The username /email attempt
.. IP address
.. Time of the attempt (this is one of the most useful pieces of information... very quick attempt suggest testing for weakness, 0 second attempts suggest automation)
.. (failed password)<< This it probably the most useful, since you can tell if some one starts with the most common passwords / tries to iterate passwords, but it's also the most sensitive information

If they are automating this, they will probably at 1st quickly try 10 attempts with no password (just to find out if there are user locks / QA / CAPTCHA they need to get pass), so the password attemptsmight not always be very revealing

I'm currently updating another plugin (no more that a few days), so I will need to get back to update this one

 

[Parsnip]

You are correct in saying the password is sensitive information, so for best practice it would be better not to show this.

Username/email, IP address, time, number of attempts, IP etc would be worthwhile info to log.

For example, I am running the 'Limit Login Attempts' plugin on Wordpress site which forwards me emails such as:

6 failed login attempts (2 lockout(s)) from IP: x.x.x.x

Last user attempted: admin

IP was blocked for 30 minutes

That plugin lets you specify an additional lock out after X lockouts. In my case, I lock users out for 24 hours after 3 short lockouts. It also appears to be tied to IPs, so the spammer's IP will be locked out only and not affect any legitimate users trying to login.

 

[tenants]

Unfortunately, permanent locks based on IP address will only ever effect legitimate users and never attackers (attackers will use proxies).

I'm quite strongly against permanent locks (or long locks), since you will never target the attacker with this type of lock

The point of these user locks is to prevent automation, if a simple top 500 password is used, then the issue is with the password.
For a good brute force, it nice to send a 100's- 1000's of threads at once (as long as it doest noticeably slow the system down), being able to use this many threads at once allows you to attempt 8.5 Million passwords in 1 day (assuming the 100 threads each seconds)

but.... even if you put the smallest lock in there (say a 30 seconds lock after 5 attempts), most users wouldn't even notice this (it would take them more than 30 seconds to attempt 5 passwords), but this would considerably slow the attack down (to no more than 1440 attempts per day!)... The brute force then becomes useless, since even in a year I'm only going to have 52 K attempts

Even if you use a top 10,000 password (like lololo), it could still take days to get this even with a small user lock


If a user does in fact use a top 20 password, then it doesn't really matter what you do with locks, if the attacker is persistent, then they will get this account

password, 32027
123456, 25969
12345678, 8667
1234, 5786
qwerty, 5455
12345, 4523
dragon, 4321
pussy, 3945
baseball, 3739
football, 3682
letmein, 3536
monkey, 3487
696969, 3345
abc123, 3310
mustang, 3289
michael, 3249
shadow, 3209
master, 3182
jennifer, 2581
111111, 2570
2000, 2550
jordan, 2538
superman, 2523
harley, 2485
1234567, 2479

Nothing can stop a user from getting these, permanent locks will just force the attacker to switch proxies, so permanent locks are pointless (The issue is with the password)
But an attacker is much less likely bother a system when user locks are in place (they don't know how bad the password is, and have many other easier targets to attempt)

I can add the Username/email, IP address, time, number of attempts, IP... Password information is quire useful, but more often than not, it's going to be empty for the first 10 attempt... and then once the attacker knows there is a lock, the brute force will be avoided, so there is not that much point in logging passwords.

>> I'll look at logs for this some time next week

 

[Parsnip]

That would be great thanks. It's a shame there's no add-ons to enforce minimum password length or complexity, or so far I haven't found any. Seems that users can make their password a single character if they want!

 

[tenants]

I've considered it, it's one of those annoying things that you're told off for when registering. Forcing password security will probably reduce sign ups.
Most people want to use passwords that they can easily remember, particularly on forums
Most of the time if they are brute forced, at most, they will only lose a few posts... nothing of high value to them

To be honest, it's not the end of the world if a normal forum account is taken... (if they care, they'll contact you and you can change the password and email them, and then make sure they use a strong password). For what reason would an attacker want to use a normal forum account (for signatures ... possible, but they would target high posting accounts, which should really use stronger passwords)

What really matters is that your admin / mod accounts aren't taken.. that's up to you to enforce passwords with those accounts. (I use IP based protection for those types of account... attackers need the correct IP address before they can even attempt to log in)

small locks will significantly reduce a brute force without annoying the users (even if they are using silly passwords), enforcing password might reduce sign ups

 

[tenants]

This resource has been removed and is no longer available for download.