A change in authentication flow can help prevent brute force bot attacks:
1. Information leakage - valid usernames & passwords discovery
2. User lockout due to bad password attempts
Instead of processing and evaluating user input in sequence gather the input and test them in a logical flow to prevent bad password attempts.
Here is one possible flow:
1. User goes to Access Manager (NAM) SSO resource (Office 365, AG PR, SSO Portal, etc).
a. User is redirected to an Access Manager login flow which implements risk checks and includes MFA via Advanced Authentication for risky authentication attempts.
2. Gather user inputs only
Note: This flow prompts for input in independent prompts that are "dynamic". Dynamic meaning that the prompt flow may differ depending on a risk evaluation and type of authentication factors configured. The following is just one example flow.
Page 1 - Form 1 prompt: username & password
Page 2 - Form 2 prompt: 2nd factor (e.g. AAF totp, smartphone, email otp, security questions, etc)
Page 3 - Your credentials are being verified, please wait...
While page 3 is displayed to user...
3. Search user store for submitted username a. If not found, wait a configurable amount of time then display generic (customizable) login error with a link to retry login (retain originally requested destination).
a. If username is found, then continue...
4. Initiate 2nd factor check
NOTE: Configurable for either a specified method (chain) or "dynamic" where user selects from all enrolled methods assigned to NAM event being used.
a. If not enrolled, display generic login error with a link to retry login (retain originally requested destination).
b. If enrolled, initiate 2nd factor method. NOTE: method dictated by configuration; either specific method or selectable by user(dynamic).
c. If 2nd factor fails, wait a configurable amount of time and then display a generic login error with a link to retry login (retain originally requested destination).
d. If 2nd factor succeeds then continue...
5. Verify LDAP password
a. If wrong, display generic login error with a link to retry login (retain originally requested destination).
b. If correct, login success, redirect user to originally requested URL.
NOTE: The login error should not leak any information to an attacker such as bad username, bad password, etc. This information should be in logs only.
by: Paul M. | over a year ago | Other
Comments
This is being reviewed.
Agreed.
Perhaps in a situation of a Brute force attack I have seen cases where the bot is not able to produce the second factor but because no failure is registered, it is allowed to continue trying without locking the account (in a situation where username/password are correct but the second factor is not obtained). Perhaps to have a policy that would either enforce a stronger (third) authentication mechanism after a configurable number of failures or tie it with a captcha functionality (" I am not a robot") type of verification.
Not sure how the captcha would work with a RADIUS authentication so perhaps limit it to web based authentications. Just a thought.
We don't use NetIQ Access Manager in our environment but the same change in authentication flow for NetIQ Advanced Authentication will also help prevent Brute force / BOT Attack at OS logon or via VPN Access (step 2, 3 and 4 will be the same).