Following the first part of the article, which explained the brute-force attack and its different techniques, the following article will enumerate the possible mitigations that can be implemented in order to protect against such attacks.
Note that there are different types of products, each business model addresses different types of users. This article will address the different solutions.
“Completely Automated Public Turing test to tell Computers and Humans Apart”; is a type of challenge-response test which can help us determine whether or not the user is human.
- CAPTCHA is often considered the ideal solution against automated attacks thanks to the nature of its functionality that requires the user’s intervention and the server’s response.
Keep the counter on the server, rather than on the client;
- If the user fails more times than the allowed number, deploy an active CAPTCHA. If the CAPTCHA from the user matches, only then check for credentials;
- It is recommended to use a proven CAPTCHA implementation, such as Google’s reCAPTCHA: http://www.google.com/recaptcha.
The Multi-Factor Authentication (MFA), also referred to as Two-Factor Authentication (TFA/2FA), is a method which requires additional input or action from the user while trying to authenticate to the account, increasing the security level of the login process.
There are a few common methods that can be applied as TFA:
- Using a dedicated OTP application (e.g. Google Authenticator, Duo Mobile, etc.) that generates a temporary, random code or that requests an approval from the user, using a notification message (e.g. Google 2-Step Verification).
- Sending a temporary, random code to the number associated with the account, via SMS, or through an automated call, or to the associated email account.
- Note that due to the risk that SMS messages may be intercepted or redirected, alternative solutions may need to be considered:
- If the out-of-band verification is to be made using a SMS message on a public mobile telephone network, the verifier shall verify that the pre-registered telephone number being used is actually associated with a mobile network and not with a VoIP (or other software-based) service;
- It then sends the SMS message to the pre-registered telephone number;
- Changing the pre-registered telephone number shall not be possible without 2FA at the time of the change;
- OOB using SMS is deprecated, and may no longer be allowed in future releases of this guidance.
The TFA can be implemented in different positions through the login flow, to avoid other flooding, enumerating and locking of accounts and it is recommended to consult with a professional party in order to find a solution that will be suitable to the organizational needs.
Locking brute-force attempts after X repetitive attempts, based on the attack’s origin IP address.
- Note that the application can inadvertently block large groups of users by blocking a proxy server (NAT IP address) or a 3G provider IP range which is shared among its customers;
- In addition, this solution alone will not protect the application completely since the attackers can perform brute-force using different IP addresses for each request.
Preventing access to a specific targeted account in the application by locking the user and releasing the lock after a short period of time (5-15 minutes). It is also possible to reduce the capabilities (e.g. view-only mode) instead of completely locking out an account;
- Note that accounts can be deliberately locked by attackers to prevent the user from using the application. This solution should only be used on highly-sensitive systems, in cases where security exceeds usability;
- In addition, the application can allow the user to regain access to his account by sending him an email indicating that the account has been locked due to multiple login failures, and allow him to reset his password or unlock the account using one-time token.
White-List IP Address
Access to the account is limited to certain IP addresses, therefore dramatically reducing the potential threat of brute-force against the login.
The application should count the number of failed login attempts to a specific user and delay the response with each attempt. By increasing the delay after X failed login attempt, the brute-force becomes impractical. Delay and incremental delays can be done by tracking the IP address or username with which the user tries to login to.
- Note that in case the attacker tries ranged brute-force attacks (brute-force on the username input instead of the password input), this mitigation alone will not be effective.
Secure Password Policy
In addition to the described solutions, it is also recommended to maintain a strong security policy to avoid account hijacking through brute-force attacks:
- Password Length should be at least 8 characters.
- Password complexity should include a combination of alphanumeric characters. Alphanumeric characters consist of letters, numbers, punctuation marks, as well as mathematical and other conventional symbols.
- Do not allow repetitive (e.g. ppppppp) or sequential (e.g. 12345678) characters.
- Do not allow a password similar to the username/email used for registration.
- Configure maximum password age and require a change of password after 3-4 months.
- For change password functionality, keep a history of hash values of old used passwords. Best practice recommends not allowing a password that was used in the most recent previous entries.
- It is also considered to use a password blacklist dictionary to avoid common passwords such as: ‘Passw0rd’, ‘Qwerty1’, etc.