Is ASM right for a very slow "Brute Force"

Hi Russel,

I've writen in the past a traditional prä-auth / reverse proxy iRule, which included:

• Normalization of username strings (e.g. removing CaSe, different representation of a single username, etc.).

• [table] based serialization of parallel login request for a single username spanning multiple TCP connections (to avoid race conditions, while waiting for AAA decissions)

• [table] based backlogging of parallel login request with identical credential sets.

• [table] based tracking the number of wrong login attemps per user-account, with the added ability to rember and supress attemps using already proven as wrong credentials (e.g. to avoid accidential lockouts caused by the user themself entering old passwords or just using a wrong keyboard layout)

• [table] based tracking the number of wrong login attemps per IP address, with some added logic so that a single IP address needs to bruteforce multiple useraccounts before getting locked.

• The repository access was implemented using [SIDEBAND] HTTP request directly to the published webservers (e.g. via BASIC or Forms auth) and included a [table] driven SSO mechanism to SSO to multiple websites (also including Cross-Domain-SSO).

If the lockout counter for a specific username has been reached a given limit, further authentication attemps from the same user would be supressed/denied for a given timeframe.

If the lockout counter for a specific IP adresss has been reached a given value, further authentication from the same user would be supressed/denied for a given timeframe.

Hope this helps to get some ideas, what could be done without Catcha, APM or IPI but instead using plain iRules.

Cheers, Kai