Planned features

For features planned in the next few versions, see the Roadmap.

This page is more for gathering feature ideas which are not yet 100% clear if and how they should be implemented.

• Special blocking handling for admin user: The "admin" user created by default in the Joomla! installer is the primary target for brute force attacks. Usually however the admin will also be the one user remembering his password best, and also the one having the possibility to access the database or the site in other ways, and therefore is anyway able to lift a block if he should be affected. So it would be good if the measures for the admin would be especially strict (e.g. less tries than for "normal" user names, and blocks are always permanently). The best practice is to rename the admin user anyway - so in addition to a separate handling it might be thought about a warning in the bfstop backend if there still is a user with username "admin".

• A useful feature might be if the administrator of the Joomla! site would be enabled to send an abuse email to the abuse address for any blocked IP address from the log. This way, maybe "script kiddies" might be discouraged from running automated attacks against Joomla! systems. The question is how many of the logged IP's actually would correspond to real attacker's addresses (instead of e.g. just a machine in a bot net, only used for carrying out this specific attack attempt). Automatic sending might be considered, but from the current point of view, at least a confirmation from an administrator for this seems advisable (to avoid being misused as a spam sender).

• More aggregated display about the recorded attempts / attacks could also be useful: Any IPs/subnets that appear more often than others, or statistics about the originating countries of most attempts, visualized as charts.

• A suggestion which has come up two times already (https://github.com/codeling/bfstop/issues/68 and https://github.com/codeling/bfstop/issues/24) is automatic whitelisting. The idea is that the IP of every user logging in with correct credentials will get whitelisted. At the moment the original author has security concerns against implementing this feature (see those two linked issues for details). If anybody can come up with a secure but easy way of implementing such a thing, it might help to improve the user experience for legitimate site users.

• As elaborated here: https://github.com/codeling/bfstop/issues/68, one way to improve the overall experience might be to have an adaptive number of allowed logins. If a failed login is perceived as an attack, subsequent attacks should be blocked with higher probability than if an attempt is perceived as an authentication attempt of a legitimate user. The remaining challenge is to come up with some policy to determine a probability by which the current attempt is an attack or a legitimate attempt to login; and then, depending on this probability, to adapt the number of allowed login attempts accordingly.

Some ideas from Marcel Waldvogel, Jürgen Kollek (2014): SIEGE: Service-Independent Enterprise-GradE protection against password scans. In: DFN-Mitteilungen, (87), pp. 40–46, 2014, ISSN: 0177-6894.

• Extension of blocking to IP ranges (subnets)
• Decrease number of attempts (also see above and https://github.com/codeling/bfstop/issues/68) if password is well-known (i.e. from dictionary).
• (checking whether actual password is similar)