I think it's a bit tricky to do and in the end doesn't really help.

First, you can't disable a user access after lets say five failed attemps for obvious reasons. Your admin would be disabled after a very short time and you would be locked out of your site. So a process which works on your mobile phone or local software, doesn't work on a web application.

The better option is to disable logins based on IP adresses, maintaining a blacklist. Best done with a timeout where the IP adresses will be freed again eg after a week. This works fine for NAS storages and the like.
However there is a downside: It doesn't really prevent brute forces. Hackers usually have a big network of computers doing those attacks. They don't care much if you block a few adresses, they can still keep it going with all the other computers.

If you really want to prevent brute force attacks, use two factor authentication which is a "out of the box" security feature of Joomla. Nothing works better against brute force attacks.

Pinging @nikosdion to add his view as he is the developer of one of the main 3rd party security tool.

We have implemented such a feature in Admin Tools Professional. Indeed, the main problem is that your Super User account can be disabled when a brute force attack is detected. Our workaround was to disable the user account but NOT block it. Instead, we send out an email with a verification code. This means that such a solution can only ever work when User Registration is set to Self - and yes, that's exactly when you are allowed to use this feature in Admin Tools Professional.

A better way to deal with brute force is Two Factor Authentication (2FA) which I implemented in Joomla! 3.2 nearly two years ago :) It doesn't matter if they know or guess your username and password. If you don't supply the 2FA code you can't log in and all you see is a generic error message that your username, password or 2FA code is incorrect. This makes it impossible (big word; better say "extremely unlikely, highly impractical and overall implausible") for the attacker to brute force your account. So out of the box Joomla! does offer a compelling way to prevent brute force attacks without causing too much distress to the user after the site has been targeted.

The better option is to disable logins based on IP adresses, maintaining a blacklist. Best done with a timeout where the IP adresses will be freed again eg after a week. This works fine for NAS storages and the like.
However there is a downside: It doesn't really prevent brute forces.

At first it didn't harm either.(if you can configure it) So why don't have it, then it doesn't have negative effects?
It can prevent brute forces. I'm an a programer and was called yesterday to a hacked page. The first thing I found in the log files were million of login tries from the same IP Address. So I think the page was just brute forced...

First, you can't disable a user access after lets say five failed attemps for obvious reasons.
You can do this for some minutes and then unlock it again. Main systems (like banking systems) work well with this concept. Especially if you can unlock your account very fast using mysql.

We have implemented such a feature in Admin Tools Professional.
So why not for joomla directly? :)

A better way to deal with brute force is Two Factor Authentication (2FA)
That's also a good solution, but why not have both? In this case two security systems are better then one. Especially because 2FA isn`t enabled by default. But you can easily enable the brute force protection by default.

Brute protection integrated into core?
Yes. A proper and flexible brute force protection would be one of the great addition to Joomla security.
But, we should start sending some pull requests to get this done ... ;)

Time-based IP blacklisting ?
Yes, with exponential lockout time. After X failures blacklist starts with eg. 1 min, next "kick" brings you 2 min, etc. And inform user/admin that he has been locked out for Y minute. S(H)e can try to reset the password after given lockout time passes by, which will then also clear the IP from blacklist.

Human users will probably stop and rethink what they are typing in after that message, or use Reset Password mechanism.
Bots will most probably blindly keep kicking, and will be locked out for a long period after short time.

Enabled by default?
Yes, if users/admins gets a proper message saying (s)he has been locked out because of X failed login attempts, and have an option to use Reset Password mechanism or try again after Y minutes

Additional ideas
IP's could be auto-purged from blacklist after some day(s), user defined, or manually.
Integrating with Fail2Ban and similar systems.

Time based lock out: That's the BEST way to cause a denial of service. Here's a very simple scenario. Adam is a troll and posts annoying messages on Bob's site's forum. He wants to keep Bob from deleting those messages. So Adam has written a script which makes invalid login attempts with Bob's user account while Adam keeps on trolling poor Bob. Bob can't log in to his site and deletes it in despair shouting "IT'S ALL JOOMLA'S FAULT!" (and he would be unfortunately right...). This also applies to all brute force "mitigation" techniques which involve shutting off user access.

Do keep in mind that, unlike a bank's system, your Joomla! username is not a secret. This is the most important bit you MUST keep from this conversation.

IP based lock out: Meh. Spoofing IPs is too trivial. I can do it quite easily with several browser extensions / proxies / libraries / download tools which allow me to send custom HTTP headers. I will say no more because this is a public resource. And yes, I do have the code to go for it. So, if the answer is "IP-based" you are asking the wrong question. Heck, I can even give you a hint. How do transparent proxies and caches like NginX and Varnish let Apache know of the real visitor's IP address? Whoops, I said too much :x

Does this mean IP-based systems make no sense? Not at all. They can stop stupid script kiddies. Please take that from a developer who does sell a security product that among many, many other features does have an automatic IP blacklist which implements all of @btoplak's ideas since four years ago. I still do NOT consider IP blocking to be sufficient or prudent. Just a simple measure against simple attacks.

A better brute force mitigation can be implemented with a service like CloudFlare but it's still not as thorough as 2FA. If you don't want to use 2FA and do worry about brute forcing you can use such a service.

Again, people, the solution against brute forcing is called 2FA, it's already present in Joomla! and costs exactly $0.00 to implement it. You are literally describing the EXACT problem being solved by 2FA. Everyone out there (Apple, Google, Facebook, Twitter, you name it) is implementing 2FA for EXACTLY this reason. Why would Joomla! even try to naively ignore the perfect solution concocted by of the best engineers on the planet and instead implement a solution fraught with problems? Use the right tool for the job. Tell your clients about the wonders of 2FA and use a free solution like Authy or Google Authenticator. Problem solved, with extreme prejudice (BONUS POINTS: They can use ridiculously insecure passwords like 1234, p@ssw0rd or IAmGod without compromising their account's security!)

FYI ebay abandoned time based lockouts because people were using it to prevent competing bidders from being able to login to their accounts and increase their bid.

@nikosdion no one said 2FA is bad as far as I can see here. And no one said it shouldn't be used. Quite the contrary, it's a very good system, if implemented properly. Security level rises when used with hardware tokens.
And even with 2FA active, IP blacklisting would be a good additional countermeasure, primarily to offload bruteforcing in the earliest stages.

Such additional layer of security, when designed and implemented carefully, should always be welcome. IMO. Even if disabled as default, the interested webadmins could activate it when they want.

It's great if you have everything in your product (didn't use it so I don't know much about it and what it implements). But the subject here is the idea of bruteforce protection integrated into a Core.

@brianteeman: True - lockout by username only is a bad idea ("time based" isn't a problem there IMO). I didn't suggest that.

Probably my explanation wasn't clear. Let me try to explain further.
Yes, I am adding a suggestion for an IP based blocking which is active only particular timeframe. Which should save some manual blacklist administration.

So, if Adam would simply try to lockout Bob The Admin by sending wrong login requests on Bob's username, what would happen is only Adam's IP would be blocked. Bob can still log in anytime.

If you say IP based blocking is futile, that would mean all firewalls of the world are futile. Which is not correct. But only a simple IP based block, without any time constraints, would be a failure and would need much more admin's attention.

The IP spoofing method would work in this setup only if Adam knows Bob's IP (simpler scenario), or/and is able to affect routing (to get any information back, much more complex). And both situations would mean Bob probably has a much bigger problem there, and no Joomla protection would help him if the attacker is able to inject himself somewhere inline on the route. And Adam would probably be more efficient playing with MITM there.

I explained my idea how a successful "reset password" should also reset the blacklist.
To enable Bob to prevent such "spoofed IP blacklistings" even more, there should also be a "whitelist". So Bob can prevent some of such attacks too.

And, username should be a secret anyway.

You miss the entire point. You are trying to fight brute force attack, not
password AND token theft. Think. I already told you how 2FA protects you
against brute forcing. Not to mention every single major Web corporation is
using time based one time passwords for 2FA, the same option offered by
Joomla, to combat brute forcing.

I got your point perfectly.
And let me repeat myself again, 2FA is fine!

I am sure adding bruteforce detection and enabling IP ACL-ing option would be a benefit for any user. Even the cheapest firewall appliance implements ACL-ing.
I even gave explanations how to prevent issues you mentioned as obstacles for such implementation.

As long as anyone can set the HTTP X-Forwarded-for header to any arbitrary
IP any IP based solution will be dangerously naive for all but dedicated
servers. If I know your IP (very easy if I am targeting you) I can
effectively block you out of your site while I do my misdeeds. Instead of
plugging a hole you end up creating a whole new different class of targeted
attack vectors.

For this reason such a solution would only make sense if the back end users
were exempt and the feature was opt in for everyone else, per user account
and globally. In short it is not very useful after all. I know how to set
up my site and server to not allow this kind of blocking and I have
emergency measures in place. The average Joomla user doesn't and shouldn't.
This is why I am against an IP based solution in the core. The advanced
users can implement a far more efficient anti brute force solution with
mod_security2 rules instead and actually benefit much, MUCH more from them
(more performant and more accurate than anything PHP based). Or they can
use a service that sits before their site like CloudFlare or Sucuri for the
same performant and accurate effect. All that if they really want to go IP
based for reasons other than brute force protection (2FA is the only
reasonable, practical and resilient cure to that with no side effects).

And if you are wondering, I do warn my clients about the IP based perils
and wanted to remove those features but alas they prefer selling THEIR
clients a bad semblance of security so here I am offering a feature I
consider to be a bad idea. At least I am being honest about it, right?

For "X-Forwarded-For" (or any similar proxy header) to be injected as a client IP, there has to be extra webserver module active. Without that module those headers are useless and won't harm anyone. And if such module is active, that means webmaster is probably not a noob, and he can additionally allow only known proxy IP addresses to pass (Cloudflare and similar publish their IP ranges).

You are talking about 0,1% (or most probably 0,001%) of all attacks. Only a big minority of attacks is carefully crafted to directly target some site, as you try to explain it. And this needs knowledge, investigation etc. Spamsquads don't have that time. Script-kiddies don't have that knowledge or time.

I am talking about protecting from the rest 99,99x% attacks, which are automated by bots or script-kiddies. And easily blocked with such functionality, additionally keeping server load low. And probably force attackers to move to an easier target.
I witness every day how blacklisting bruteforce attackers on iptables helps lowering server CPU load for 30% to even 60%. That's how persistent they are. And they're not made manually.

After all, why on earth would any serious attacker need to lockout a webmaster? And what good would that do? Webmaster can still access his site by FTP, control panel, any dbadmin tool, maybe even SSH. And disable the blocking in a matter of seconds, and eventually disarm blacklisting functionality if needed. The only effect of a such "lockout superadmin access to Joomla" attack would be that webmaster actually get's informed immediately when his website is being attacked. No, the attacker would rather want to be kept stealthy as long as possible, and not to alarm the webmaster about their conduct.

According to your very flawed logic brute force attacks are also
impractical. Yet they happen. Please do not touch any core code. You
seriously do not understand application security.

An attacker will use ANY attack vector at their disposal. Remember the last
high priority issue we fixed in Joomla! update? It required a cryptanalyst
to figure it out. Once the POC was out (a month after out fix) everyone and
their dog performed this attack against Joomla sites. So what was a 0,001%
attack now became a 99% attack. If I release a POC for IP spoofing (mind
you that the aforementioned header is processed BY EVERY MAJOR HOST OUT
THERE BY DEFAULT) everyone will use it. It is five lines of code, just one
if you are using curl. So do you want to guess again if implementing the IP
lockout will lead to an increase in the attack area?

Στις Σάβ, 18 Ιουλ 2015 - 11:57 ο χρήστης Bernard Toplak <
notifications@github.com> έγραψε:

For "X-Forwarded-For" (or any similar proxy header) to be injected as a
client IP, there has to be extra webserver module active. Without that
module those headers are useless and won't harm anyone. And if such
module is active, that means webmaster is probably not a noob, and he can
additionally allow only known proxy IP addresses to pass (Cloudflare and
similar publish their IP ranges).

You are talking about 0,1% (or most probably 0,001%) of all attacks. Only
a big minority of attacks i carefully crafted to directly target some site,
as you explain it. And it needs knowledge, investigation etc. Spamsquads
don't have that time.
I am talking about protecting from the rest 99,99x% attacks, which are
automated by bots or script-kiddies. And easily blocked with such
functionality. additionally keeping server load low. And probably force
attackers to move to an easier target.
I witness every day how blacklisting bruteforce attackers on iptables
helps lowering server CPU load for 30 to even 60%. That's how persistent
they are. And they're not made by hand.

After all, why on earth would any serious attacker need to lockout the
webmaster? And what good would that do? Webmaster can still access by FTP,
control panel, any dbadmin tool, maybe even SSH. And disable the blocking
in a matter of seconds, and eventually disarm blacklisting functionality if
needed. The only effect of a such attack would be that webmaster actually
get's informed immediately when his website is being attacked. No, the
attacker would rather want to be kept stealthy as long as possible, and not
to alarm the webmaster about their conduct.

—
Reply to this email directly or view it on GitHub
#7454 (comment).

I'll fold here, it really doesn't make sense repeating myself. Obviously you read and comment only some parts of the posts, skip the others, and try to bend the subject to support your theory. Or you don't read / understand at all.

I don't have the time and don't need to prove you're wrong. It will probably result only with more insults. You aren't open for discussion, or accepting any healthy criticism. So, whatever you say - you have to be correct, no questions asked!

I leave to others to read what I've said and do their homework to investigate.

And, you're the one having strange concepts of security, and telling nonsense. No serious hosting provider injects XFF header automatically into a client IP header by default. That would be a major flaw! Just think about it - in that scenario faking access logs or avoiding Apache IP authorization directives (etc.) would be a child's play!! So stop talking nonsense and do your homework before posting.
But, you can try to prove me wrong, with some links confirming that Dreamhost, 1&1, GD or similar convert XFF to client IP header by default (no reconfiguring involved).
FYI, for injecting XFF header as IP header automatically additional module like Apache "mod_remoteip" or Nginx "ngx_http_realip_module" has to be enabled and configured, and that isn't by default for sure.

If no facts (links) are presented here I won't care to respond anymore. When I'll prepare some real code I'll publish for comments.
And I'll try to send my concerns with some bits of your code to you privately, maybe you'll care for a respectful discussion.

I will let you read the code in Joomla itself. Unlike you I actually DO
KNOW what I am talking about. You insist on being wrong. Whatever dude.
Only one of us actually writes a security component for a living. I will
let the readers decide who knows and who does not.

PS: I do put my code where my mouth is. Do so yourself and then we will see
if you can live with the consequences. I will see to it. Consider this a
promise.

Στις Κυρ, 19 Ιουλ 2015 - 02:18 ο χρήστης Bernard Toplak <
notifications@github.com> έγραψε:

I'll fold here, it really doesn't make sense repeating myself. Obviously
you read and comment only some parts of the posts, skip the others, and try
to bend the subject to support your theory. Or you don't read / understand
at all.

I don't have the time and don't need to prove you're wrong. It will
probably result only with more insults. You aren't open for discussion, or
accepting any healthy criticism. So, whatever you say - you have to be
correct, no questions asked!

I leave to others to read what I've said and do their homework to
investigate.

And, you're the one having strange concepts of security, and telling
nonsense. No serious hosting provider injects XFF header automatically into
a client IP header by default. That would be a major flaw! Just think about
it - in that scenario faking access logs or avoiding Apache IP
authorization directives (etc.) would be a child's play!! So stop talking
nonsense and do your homework before posting.
But, you can try to prove me wrong, with some links confirming that
Dreamhost, 1&1, GD or similar convert XFF to client IP header by default
(no reconfiguring involved).
FYI, for injecting XFF header as IP header automatically additional module
like Apache "mod_remoteip" or Nginx "ngx_http_realip_module" has to be
enabled and configured, and that isn't by default for sure.

If no facts (links) are presented here I won't care to respond anymore.
When I'll prepare some real code I'll publish for comments.
And I'll try to send my concerns with some bits of your code to you
privately, maybe you'll care for a respectful discussion.

—
Reply to this email directly or view it on GitHub
#7454 (comment).

Why there are so many third party apps that offers brute force protection if it's useless? I'm managing many joomla sites. All pages uses a brute force protection and I never had amy Problem with it.

Once I was called for a Page that was under brute force attack. I only installed this addon and the server load went down by 50%. Some hours later the attack stopped. This site was not compromised!

Having written one myself I can tell you that it does work BUT there are
also issues. Yes it protects you against script kiddies. Yes it opens a
sneaky directed Denial of Service attack vector. Weigh the two and choose
what to do. Bottom line: be informed and if crap hits the fan ask for
support by the developer. Since with Joomla you can never be adequately
informed or receive support from the developer such a feature would be
wrong for the Joomla core.

Στις Κυρ, 19 Ιουλ 2015 - 15:50 ο χρήστης RichardEb notifications@github.com
έγραψε:

Why there are so many third party apps that offers brute force protection
if it's useless? I'm managing many joomla sites. All pages uses a brute
force protection and I never had amy Problem with it.

Once I was called for a Page that was under brute force attack. I only
installed this addon and the server load went down by 50%. Some hours later

the attack stopped. This site was not compromised!

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/7454
http://issues.joomla.org/tracker/joomla-cms/7454.

—
Reply to this email directly or view it on GitHub
#7454 (comment).

You have also to notice that 2FA is a uncommon thing at the moment. Most websites/services don't use it at the moment. So of my customers explicit don't want 2FA because the login process needs additional time.

Maybe there is a compromise: There is a lightweight solution to prevent brute forces. After 3 failed Logins (per username and/or IP) the next Login(s) take an additional second (each). So the brute force of a 8 char password will take about 6923519 years. So a non distributed brute force will fail and an distributed brute force will be much harder.

On the other hand there is no possibility do DOS the site because of the feature. (The "normale" user don't realize the extra second and there is only an extra second if a brute force is running)

@IP Spoofing:

IP spoofing on the internet isn't as easy. Every "good" ISP will filter packages that don't match the IP address that was assigned by the ISP. It doesn't matter if HTTP headers are modified. The TCP/IP package itself contains the ip too. If he wants to change the IP using a proxy server, he has to find many fast proxys. It's sometimes hard to just found one fast proxy

About delays: what we have seen in the real world is ten to twenty requests
going out the same time, 10 second pause, repeat. So this solution does not
work. Yes, I had thought of implementing it.

IP spoofing: do note that I am NOT talking about forged TCP/IP headers but
you do. In your context you are right. In the context of the discussion we
were having you are wrong. Hosts do NOT filter out the X-Forwarded-For
header. This is the problem. Sure enough you can filter it with a
mod_security2 rule if are not using a reverse proxy, cache or CDN. But the
majority of small sites you are talking about do not even have thus option.

Regarding 2FA: this WAS indeed and issue back in 2012 when I proposed the
core feature. Not any more! I am using 2FA with Google, Microsoft, Amazon,
GitHub, Slack, Facebook, Twitter and even my host (SiteGround). All these
services have announced that 2FA will be mandatory by end 2016. Joomla is
ahead of the curve for once :)

Στις Κυρ, 19 Ιουλ 2015 - 19:44 ο χρήστης RichardEb notifications@github.com
έγραψε:

@IP https://github.com/IP Spoofing:

IP spoofing on the internet isn't as easy. Every "good" ISP will filter
packages that don't match the IP address that was assigned by the ISP. It
doesn't matter if HTTP headers are modified. The TCP/IP package itself
contains the ip too. If he wants to change the IP using a proxy server, he
has to find many fast proxys. It's sometimes hard to just found one

fast proxy

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/7454
http://issues.joomla.org/tracker/joomla-cms/7454.

—
Reply to this email directly or view it on GitHub
#7454 (comment).

Reset priority according to docs https://docs.joomla.org/Bug_and_Issue_Tracker_Priority

What do you think about a challenge(captcha/question) at least for the backend as default? This will also require additional system resources at the attacker site but don't allow ddos attacks.

You could also show the captcha only after 3 failed logins

This is a reasonable request and I can see no security issues with it. It
will be slightly annoying to users (more than 2FA with YubiKey anyway :p)
but it would work towards brute force prevention the same way 2FA does. Do
you think that having an option in the two login modules (front-end,
back-end) and the Users component (for the front-end login page, not
module) would be an acceptable method? If so I can try writing this feature
and make a PR this week.

On Sun, 19 Jul 2015 at 21:16 RichardEb notifications@github.com wrote:

You could also show the captcha only after 3 failed logins

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/7454
http://issues.joomla.org/tracker/joomla-cms/7454.

—
Reply to this email directly or view it on GitHub
#7454 (comment).

@nikosdion
It's only supposed to be the basic security. So it should be turned on by default. But the user will only see the captcha after 3 failed attempts(brute force in progress?!?!?!) And the admin can disable it if he turns on 2FA to secure the login

The only problem I see with having it ON by default is that it means that
all users will need to setup and configure the captcha plugin

On 19 July 2015 at 19:42, RichardEb notifications@github.com wrote:

@nikosdion https://github.com/nikosdion
It's only supposed to be the basic security. So it should be turned on by
default. But the user will only see the captcha after 3 failed
attempts(brute force in progress?!?!?!) And the admin can disable it if he

turns on 2FA to secure the login

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/7454
http://issues.joomla.org/tracker/joomla-cms/7454.

—
Reply to this email directly or view it on GitHub
#7454 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman

I think joomla can provide an own captch module that don't need any configuration. I think this is a nice to have anyway because recaptcha need a google connection.

@brianteeman That would be DISABLED by default so that we don't break
sites. Moreover, not all site owners will want to force themselves or their
users using a CAPTCHA when logging in. I see this as an opt-in feature for
sites with a moderate brute forcing issue. If a site has a really big brute
forcing issue it'd be better to use a third party service sitting in front
of the server to deflect the unwanted traffic and not waste server
resources anyway. Makes more sense this way?

On Sun, 19 Jul 2015 at 21:47 RichardEb notifications@github.com wrote:

@brianteeman https://github.com/brianteeman

I think joomla can provide an own captch module that don't need any
configuration. I think this is a nice to have anyway because recaptcha need

a google connection.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/7454
http://issues.joomla.org/tracker/joomla-cms/7454.

—
Reply to this email directly or view it on GitHub
#7454 (comment).

Currently, Captcha are handled by plugins. We have the ReCaptcha one shipped with core, and this one needs to be configured. It also needs to be selected in the global configuration which one you want to use.
I would be strongly against having an additional "own" plugin and also against having it enabled by default. To many moving parts and possibilities to lock someone out of their site.

@Bakual it also needs to talk to google. Not every one like this because of privacy policys

That's why the captchas are plugins. You can chose another one if you don't like the Google one. There are a lot of alternatives on JED.

@Bakual But why not in the core version if google is in it?

We have in core the most used Captcha version.
Why should we maintain in core another one? When there are many alternatives already available?

Thomas please read what I wrote. I did NOT suggest writing a new CAPTCHA
plugin. That would be a silly waste of my time. I said that we can add an
option to use one of the enabled CAPTCHA plugin in user login just like we
do in user registration.

Why a toggle? Because I want CAPTCHA in my contact form but NOT my
front-end login form. And so on for every one of us. Telling us that if we
enable CAPTCHA it has to be forcibly enabled for everything is just plain
wrong and the reason why everyone and their dog wrote their own CAPTCHA
plug-ins and features.

Στις Κυρ, 19 Ιουλ 2015 - 22:41 ο χρήστης Thomas Hunziker <
notifications@github.com> έγραψε:

We have in core the most used Captcha version.
Why should we maintain in core another one? When there are many
alternatives already available?

—
Reply to this email directly or view it on GitHub
#7454 (comment).

@nikosdion My answer wasn't to you. It was meant to Richard.
I fully agree with you.

@Bakual Sorry! It came directly under mine without an at-mention so I
assumed it was a reply to what I wrote :)

On Mon, 20 Jul 2015 at 00:48 Thomas Hunziker notifications@github.com
wrote:

@nikosdion https://github.com/nikosdion My answer wasn't to you. It was
meant to Richard. [image: ]
I fully agree with you.

—
Reply to this email directly or view it on GitHub
#7454 (comment).

@nikosdion When I started writing, yours wasn't there

@Bakual Oh, don't you love text communication? :D OK, more seriously. Would you like me to try and implement this feature this week?

I think it would make sense, yes.

• Adding the existing captcha mechanism to login views/modules.
• Opt-In feature

Thank you all for the discussion. I would like to see such a solution (Captcha only after x failed login attempts) in the core, but only as an opt-in feature.

It would be great if you could provide it @nikosdion!

@Kubik-Rubik If I were to implement this I might just as well leave things as they are. Because your suggestion has a major logical fallacy. You propose displaying a CAPTCHA after X failed login attempts. Since PHP is a stateless language by design the only way to compare the number of failed login attempts (Y) against the value X is storing a rolling counter Y in the user session. However, the user session is a. dependent on a cookie and b. stored in the database.

Item (a) is effectively a backdoor. If I reset my cookie cache every time I try a login to your site then Y will always be 0, therefore it's as good as not having a CAPTCHA at all.

Item (b) is equally bad because it can be used in a DoS attack: we need to waste resources creating a new session for every login attempt and we might crash the table with the number of sessions we need to open. Of course that's a problem with Joomla! ever since it was called Mambo and we have not found a compelling solution (probably in J! 4, requires a b/c break).

You can save counter Y in the database I hear you say. Well, yes, you can. But then you have two write queries for each login attempt. The one from item (b) and the one to store counter Y. Therefore we make it more likely that a DoS attack would succeed with less resources on the attacker's side. In fact we risk crashing two tables, #__session and #__users.

So I guess we came back at the beginning of the discussion. I can give it the rough treatment (opt-in CAPTCHA for every login) or I can tell you once again to use 2FA. You are the PLT, it's your choice. I can only warn you about a very bad idea, not stop you from finding someone willing to implement it :p I just need you to tell me what the PLT decides so I know if I'm going to spend time on it or not.

@nikosdion Thank you for your valued response. I agree with your arguments and also prefer the 2FA solution (and for my personal use an htaccess protection for the administration folder). I think the opt-in CAPTCHA for every login attempt is a possible solution besides 2FA. I mean for users who for whatever reason don't want to use 2FA.

Regarding the sessions in the database, did you plan (in the architecture sprint for J!4) to change this?

Can we just close this. We already have 2fa in the core which can do this
AND you can protect your site with htaccess. Plus a gazillion 3pd options
at both the extension and hosting level.

This isnt going anywhere productive and there are far more important areas
to spend time on where solutions do not exist

On 20 July 2015 at 19:40, Viktor Vogel notifications@github.com wrote:

@nikosdion https://github.com/nikosdion Thank you for your valued
response. I agree with your arguments and also prefer the 2FA solution (and
for my personal use an htaccess protection for the administration folder).
I think the opt-in CAPTCHA for every login attempt is a possible solution
besides 2FA. I mean for users who for whatever reason don't want to use 2FA.

Regarding the sessions in the database, did you plan (in the architecture
sprint for J!4) to change this?

—
Reply to this email directly or view it on GitHub
#7454 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

For me having the option to require the captcha on every login is a good compromise.
I wouldn't add more logic to it (like having it trigger only after some failed attemps), just the same we have in registration and for the contact form.

Not sure how useful it really is, but since the code is already present in other places, it shouldn't require much to implement it in the login forms as well.

I am with @brianteeman on this one for one simple reason: depending so heavily on the availability of a 3rd party service to access your site (administrator or front end) WITHOUT a redundancy option is kinda extreme. 2FA got a nice redundancy, captcha hasn’t. So please don’t impose captcha everywhere.

So please don’t impose captcha everywhere.

Nobody said to impose it. It would be opt-in.
I would be strongly against making it required as I don't like captchas at all.

For my point, 2FA answer this topic.
If bruteforce happens, you just need to be able to react(manualy) or something(automaticaly) to activate 2FA if you dont need this all time.
Another way could be to force user to use strong password :p

@nikosdion Just want to give you another way than Item (b) BDD: store in File eg: "username.tmp" but i think this lead to Dos too.

File based storage is even worse. Not only it's slower (since the parsing
is done by unoptimised user-space code written in a scripting language
instead of an optimised, high priority service written in C) but it also
doesn't deal with concurrency which is a major aspect of brute force
attacks. If you really want to protect your site efficiently you need to
use a firewall in front of your server's Internet connection. If that's not
acceptable (cost, complexity, ...) the next best thing is 2FA.

A CAPTCHA can be viewed as the poor cousin to 2FA. Instead of having an
opt-in, high security feature you get a forced, low security method for
everybody.

@Bakual The major problem I see reading our code is that we need to bake in
CAPTCHA support to our com_users component and the modules. This will be
a b/c break for 3PD login modules if you enable CAPTCHA in com_users. You
can't just enable CAPTCHA for just a login module. Is this b/c break
acceptable in Joomla! 3 or should I just forget about it?

I think it is acceptable since it is opt-in.
The user just needs to make sure to update his modules or use the core one if he wants to use the new feature.

I'm closing this issue as stated we have two factor available. If someone wants to contribute any code discussed here then they can and can reference this PR but I don't think there is anything more to add to this issue. Thanks.