Protect Your Passwords Against Brute Force and Dictionary Attacks

Brute force and dictionary attacks can both be prevented with similar techniques. Let’s start with some basic remedies that should be easy to implement and that can have a huge impact on online tracking. As these represent best practices, do consider implementing both as a baseline measure.

The first method is Multi-Factor Authentication (or MFA). As discussed in the previous section, MFA can prevent an attacker from logging in with stolen credentials if they miss the second factor, such as biometrics or devices. While this won’t prevent the attack itself, since an attacker can find a hashes dump and crack them offline, it will make any cracked hash useless.

The second option is locking accounts, which follows the same principle. With this method, an account will be locked after a certain number of failed attempts. A locked account will stop an attacker, or at least slow him down, when doing an online brute force or dictionary attack. Yet it is completely useless against an offline attack. Since an attacker only needs to try it one time after cracking the password, they will not get locked out.

Using CAPTCHA is another method to prevent online attacks. It slows down or completely stops automated attacks, but if the attacker has gained the plaintext of a hash offline, using CAPTCHA will not help because the attacker is most probably human.

You can prevent the worst from happening by disabling administrator and root accounts for your machines, or at least disabling the access to them from outside the corporate network. Even if an attacker finds the password, cracks it, and tries to log in, this will stop them from accessing the administrator accounts. Again, this will be of no use when the attacker is inside the network. So how do we prevent offline hacking?

The best solution, and probably the only one available, is to use a strong, random password.

Don’t use words from a language, whether an imaginary or a real one. For example, there are word lists for the Klingon language to crack passwords. Steer clear of commonly used passwords as well. Your password may look safe at first, but if it uses a word or a common password, its security will be very low.

So how can one enforce the use of strong passwords? It’s not possible for the most part. We cannot force our users to use random and uncommon passwords that don’t rely on words. A strong password policy is an option. For example, one that mandates passwords must contain 10 characters, at least one number, one lowercase letter, one uppercase letter, and a special symbol. Users can and will still find common passwords (that can be even based on words like “password”) that will meet the requirements but are still unsafe. To counter this, it can be a further requirement to refresh passwords regularly, such as every three months.

Requiring that passwords are updated often has a couple of advantages. Once the attacker cracks a hash, it might be already too late to use it. Depending on the refresh interval, the password might already be changed. Another option is to keep a history of the old passwords, forcing users to come up with new passwords. We can even extend this to check if the new password contains the old password, username, or other information, so that they do not just add another number at the end of the password and call it a day. This will make the passwords less common, since each time the users need to change their password, there will be fewer common passwords left available to them.

If, and only if, the user follows the best practices of not using words and common passwords, the hashes will be harder to crack with word lists and take much longer with brute force attacks. In the next lesson, I will teach you how to prevent rainbow table attacks on your application passwords.