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 attack lists.
What is credential stuffing?
A related attack is credential stuffing. Cybercriminals use known credentials (usually obtained illegally) and test them across multiple websites until they get a 'hit.' Credential stuffing attacks often work 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 password 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) with password security best practices administrated.
- Encourage users to use a password manager including a secure password generator.
- 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.
