Project

General

Profile

Actions

Feature #52170

closed

Add brute force protection to TYPO3 backend

Added by Torben Hansen over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Target version:
Start date:
2013-09-22
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

TYPO3 misses a brute force protection for the backend login. Login attempts for remote attackers should be temporarily disabled, if a configurable amount of login failures is reached.

Actions #1

Updated by Gerrit Code Review over 10 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23953

Actions #2

Updated by Gerrit Code Review over 10 years ago

Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23953

Actions #3

Updated by Marcus Krause over 10 years ago

Hey Torben,

thank you for your patch. Following, I refer to your patchset 2.

I consider it a good idea to take care about brute-forcing. Having a maximal number by IP for login attempts is good. Please make it configurable via install tool as planned (your note in your code). But please do not enable it by default! e.g. "maxAuthAttempts=-1"

Introducing a separate table is good; naming is not. It should be called sth. like sys_auth_attempts and should contain also the TYPO3 context (BE,FE). So we could also use it for Frontent Users, too.

The newly created class IpUtility suggests to contain generic IP related code. Your code is about blacklisting authentication requests by IP. IMHO naming should cover this by being more specific.

Additionally, all methods are static and by that, hard to test (unit tests). Furthermore, the methods retrieve the IP address on their own. However, the IP addresses should be at least method parameters.

Failed login attempts caused by blacklisting should not throw an exception. Please make sure, that such attempts are properly logged!

Actions #4

Updated by Philipp Gampe over 10 years ago

I think the code should be introduced as a service class and not as a utility.

Please also mind that some people use IPv6 addresses, thus the code should cover that too. IPv6 addresses need to be blacklisted by the whole /64 prefix as the /64 suffix is for users only.

Actions #5

Updated by Martin Muskulus over 10 years ago

The IPv6 prefix length can vary from provider to provider.

http://tools.ietf.org/html/rfc3177 recommends /48, but allows /64 and even /128
http://tools.ietf.org/html/rfc6177 supersedes 3177 and recommends /56

Depending on what RFC providers implement they assign /48, /56, /64 or even /128 for sites/users. So you can't be sure what prefix length to block until you request IP databases for the corresponding net.

Keep in mind that such a blocking mechanism does not help against bot nets at all.

Actions #6

Updated by Torben Hansen over 10 years ago

Issue can be closed. I'm going to provide this feature as an own extension.

Actions #7

Updated by Philipp Gampe over 10 years ago

  • Status changed from Under Review to Closed

Closed on author request.

Actions

Also available in: Atom PDF