Brute force attack mitigation 101

You will often hear the much-repeated, yet still mistaken, mantra that there’s nothing you can do to stop a brute force attack. The truth is that while the odds are stacked in favour of the determined attacker, that doesn’t mean that mitigation methods cannot be effective.

Trying to write a meaningful history of the brute force attack is pointless. The bad guys have been trying to guess passwords to accounts that don’t belong to them since, well, forever. Back in the day, hackers would use various techniques for educating those guesses; everything from dumpster diving (where skips and bins outside businesses were raided in order to find documentation containing login information), through to social engineering (conning staff into handing over the password), and, of course, the use of commonly implemented weak strings.

It’s the latter that quickly became an automated task, with savvy hackers setting a database of likely words on the task as a batch process, and then sitting back until the crack was complete. These became known as dictionary attacks, and cracking tools such as Cain and Abel, John the Ripper, and L0phtCrack became popular methods of executing them.

The rise of the dictionary attack

Dictionary attacksDictionary attacks succeed, in the most part, because users are lazy when it comes to password choice. Dictionary words are easy to remember, even if modified with numbers or special characters that give the user a false sense of additional security. As well as using, quite literally, words derived from a dictionary, these attacks also include those modified variations in the compiled attack listing. This is why more complex passwords that avoid the use of dictionary words and simple, known, variations are always recommended. The trouble is, while dictionary attacks can be avoided by using these more complex password strings, the same cannot be said for brute force attacks.

These work by calculating every possible password, and testing each one to see if it works. Obviously, the shorter the password the quicker it can be cracked using this technique. Less obviously, the resources required to brute force a password grow exponentially with an increase in string size rather than in a linear fashion. How long, in theory, a password or encryption key will take to break in this fashion depends not only on the key size, but also on the resources available to throw at the attack itself.

This is where the attack methodology has evolved the most in recent years, with a move from a single machine doing the donkey work from a single IP address, to the likes of the 2013 Github depositary attack, when it was thought that a botnet employing at least 40,000 IP addresses was used. And that’s only the half of it.

The power of GPU

More powerThese days, any hacker worth the name will not be bothering with just throwing CPU (Computer Processing Unit) power at the brute force problem, but will be using GPU (Graphical Processing Unit) power instead. If the target that needs to be brute-forced is available locally, rather than a live system that should have a lockout of some sort in place after so many incorrect login attempts, then the attacker gets to play uninterrupted. An example of this could be an encrypted password database that has been downloaded during a server breach.

In order to crack these password hashes into plaintext, it used to be the case that CPU power would falter when faced with complex passwords that could take years, or decades, to break. However, by employing relatively cheap, and immensely powerful, GPUs (often strung together in parallel) and loading rainbow tables (precomputed lists for reversing cryptographic hash functions) onto fast solid state drives, those times can be reduced to minutes. Today, the cracking tools of old are often replaced with the likes of Hashcat and Rainbow Crack.

The double whammy of advanced GPU resources and generally weak password usage is hugely problematic. Particularly when you take into account that last year one report* found that 47% of people were using passwords that were five years old, and 21% were still using 10 year-old passwords. That same survey suggested that 73% of accounts were ‘protected’ by duplicate passwords used elsewhere, and 54% of people used five or fewer passwords across their entire online life. If a database containing those is breached, the keys to multiple kingdoms can easily be discovered.

For MSPs, ensuring that customers employ a robust password policy is essential best practice in today’s threat laden world, and critical when it comes to protecting against brute force attacks.

* Source: TeleSign Consumer Account Security Report click here to view.

 

5 things to consider when defending against brute force attacks
  1. Don’t simply assume that system login lockouts will stop brute force attacks. If the password database has been copied and downloaded during a breach then it becomes a sitting duck. Employing regular, enforced, password changes helps mitigate the risk.
  2. Don’t rely on hashing of passwords alone to defeat brute force attacks, you need to add salt (a random set of data). A hashed password uses a one-way mathematical function to turn it into a value that makes it all but impossible to reconstruct (but rainbow tables align known hashes with passwords from compromises). Salting adds a random value before encryption, rendering rainbow tables largely useless.
  3. Make sure that strong and current encryption algorithms are employed, rather than old ones with known weaknesses that the bad guys will be all over like a cheap suit.
  4. Do encourage the use of password management systems as these should encourage users to employ more complex and secure (and truly random) passwords, without reuse, in the first place.
  5. Apply the principle of least privilege. In other words, ensure that all users only have access to those resources that are absolutely necessary to their job function. Never use a domain administrator account as an SQL database connection account for example.

 

Find out more about how to defend against this type of attack and what tools you need to protect your networks by downloading our free Cyber Threat Guide

Want to stay up to date?

Get the latest MSP tips, tricks, and ideas sent to your inbox each week.

Loading form....

If the form does not load in a few seconds, it is probably because your browser is using Tracking Protection. This is either an Ad Blocker plug-in or your browser is in private mode. Please allow tracking on this page to request a trial.

If this issue persists, please visit our Contact Sales page for local phone numbers.

Note: Firefox users may see a shield icon to the left of the URL in the address bar. Click on this to disable tracking protection for this session/site