A dictionary attack is a type of brute force attack that typically involves a threat actor attempting to log in to one or multiple accounts using a 'dictionary list' of common words and phrases and/or usernames used by individuals and businesses.

Cybercriminals generate permutations of words or character sets, repeated passwords, or variations - until they find a winning combination.

Why do dictionary attacks work, and why are they so common?

Poor security habits like reusing passwords or variations, or using common ones, make dictionary attacks devastatingly effective.

In more targeted dictionary attacks, criminals may even research individual users' online presence (from websites to social media accounts) to determine their interests, identify standout words or phrases, and add them to the dictionary lists.

A related attack is credential stuffing. Cybercriminals use known credentials (usually obtained illegally) and test them across multiple websites until they get a 'hit.' And it works remarkably well. 

Troy Hunt, creator of Have I Been Pwned (data breach aggregator), finds that every time he loads a breach, he's "seeing anywhere up to 60% or more of accounts already in the system anyway". 

The 2019 Verizon Data Breach Investigations Report suggests that stolen and reused credentials are implicated in 80% of hacking-related breaches.

An example of an (embarrassingly) successful dictionary attack

You may remember the 18-year-old who publicly admitted to pranking some very high-profile accounts, including Barack Obama and the official feed for Fox News? Hacker GMZ used a dictionary attack to access the account of a Twitter support staffer, and the password 'happiness' struck gold.

 

What are common dictionary attack vulnerabilities, and are your applications at risk?

  • Your CMS administration login is exposed: The administration login is available to anyone and may be subject to brute force or credential stuffing attacks.
  • Sensitive URLs, such as your admin page, are accessible publicly.
  • The application doesn't force users to use a strong password during registration, so you end up with words like happiness, password and 12345.
  • Or – the application doesn’t enforce password requirements.

How can you mitigate dictionary attacks on your applications?

 

  • Require users to use long and strong passwords (ideally passphrases).
  • Encourage users to use a password manager.
  • Use CAPTCHAs after multiple failed logins.
  • Rate limit login attempts to lock users out after repeated unsuccessful attempts within a short timeframe.
  • Lock down administration access to specific IP addresses.

How RedShield helps mitigate dictionary attacks

 

First, we IP restrict access to your administration interface, and implement an IP whitelisting shield to lock down sensitive URLs to specific IPs.

We can also provide rate limiting for login attempts, and/or lockout IP addresses attempting to brute force a login.

We parse login requests and assess the user's password for complexity. We can enforce password lengths or character complexity requirements based on your organization’s password policy, and/or to meet standards like NZISM.

If a user’s password does not meet the required complexity, we redirect them to a "reset password" page on the site and request a stronger password. 

And to mitigate similar attacks such as credential stuffing, we compare passwords against HaveIBeenPwned's database, and if compromised, require a reset. 

Fixing broken application security functionality

If your application sends back passwords in server responses, the password reset functionality is misconfigured, or password is sent in GET method, we can help.

Our Application Security Analysts (ASAs) – specialist security developers – will analyse the functionality and vulnerabilities present in your application(s), and propose mitigations.

Further layers of security to protect against authentication attacks 

If a web application displays informational error messages on login failure, an attacker can find out whether a user exists or not. They can then perform exploits such as dictionary attacks to obtain valid credentials and log in as a legitimate user.

To mitigate username enumeration, we rewrite server responses to reduce the chance of adversaries discovering valid usernames. 

And, of course, we can add SMS-based or Time-Based One Time Password (TOTP) Second Factor Authentication (2FA) to your entire application stack.

Learn more about RedShield's web app authentication solutions

Get in touch with RedShield's Solutions Architect team to discuss options for protection from authentication attacks.

 

All Knowledge base

See how we can shield your web applications and APIs

Get a free trial or talk to one of our experts

Free trial
or
Talk to us