The Verizon Data Breach Report of 2020 provides a comprehensive analysis of the source of many high-profile breaches for 2020. While phishing leads the way, hacking using stolen credentials for an authentication attack follows closely behind.
To quote Verizon: "…it must be said that hacking and even breaches in general (at least in our dataset) are driven by credential theft. Over 80% of breaches within hacking involve brute force or the use of lost or stolen credentials."
And in 2021, the very same attack vector ranked seventh on the OWASP Top 10.
So, how do attackers use stolen credentials to breach your data?
Authentication and authorization attacks aim to access your resources without the correct credentials.
To do this, attackers exploit stolen session IDs or login credentials including usernames and passwords to impersonate legitimate users of your web applications. Tactics to gain unauthorized access to user accounts commonly include credential stuffing/password spraying, where the attacker tries out a list of username/password pairs gained from breaches of other websites, and brute force attacks – also known as dictionary attacks, where multiple commonly-used passwords from a dictionary (or another source) are tested against a single account.
Any users who have reused the same passwords across multiple sites, or who have used a weak password, are at risk of having their accounts cracked.
However, it's not just account takeovers that you need to worry about. Session hijacking, and the related session fixation, allows the attacker to take over an authenticated session by obtaining the session ID (or token) and pretending to be the authorized user. They can then do anything on the network that the real user can do. For example, if permissions permit, they could view and access bank accounts, help themselves to HR records, and change vendor bank account numbers to divert payments into their own pockets.
All in all, the damage to your organization can be significant.
What best practices should you apply to protect your web apps from authentication attacks?
1. Password strength checks - require a 'strong' password to make guessing it either manually or using automation unlikely, if not near impossible. This includes disallowing a user to create a password that is too short (less than eight characters) or in some cases, too long (max. of 64 characters to avoid long password denial of service – DoS). A strong password should allow use of all available characters, including Unicode and whitespace. Provide an on-page password strength meter, and block acceptance of any passwords used before or previously breached, or common passwords like password and 12345678.
2. Check passwords against breaches - make sure users aren’t using passwords already known to attackers by checking against databases of known-breached passwords. This prevents common passwords from being reused, and encourages users to create random, unique passwords.
3. Harden your web applications against enumeration attacks – deploy reCAPTCHAs (a CAPTCHA system that enables your web host to distinguish between a person and an automated website visitor), or another form of bot detection which requires the user to verify they are, in fact, human.
4. Rate limit login attempts - lock users out after they've made repeated unsuccessful attempts to log in within a short timeframe to protect against automated attacks.
5. Require multifactor authentication – considered the best defence against most password-related attacks, including brute-force attacks, MFA introduces an unknown and unpredictable account verification factor to the standard authentication mix of password and user name. According to OWASP, analysis by Microsoft suggests that MFA would have stopped 99.9% of account compromises.
6. Implement real-time logging, monitoring, and reviewing of authentication functions (from password failures to account lockouts) - to detect credential stuffing and brute force attacks – successful or otherwise.
7. Improve your session management – make each session unique to each user and difficult to predict. OWASP recommends using the following:
- A trusted server for creating session identifiers
efficient algorithms to ensure the random generation of session identifiers
- Logout functionality that completely terminates the associated connection/session
- A short-as-possible session inactivity timeout (less than two hours)
generating a new session identifier when a user re-authenticates or opens a new browser session
- Implementing periodic termination of sessions (especially for critical service applications)
- And access controls that protect all server-side session data from unauthorized access by other users.
RedShield can implement these best practises across all apps, in a shield layer, without requiring application code changes
We implement web application shields to apply strong authentication controls and add further layers of security.
We enforce password strengthening with minimum/maximum lengths to user passwords across the entire organization, and apply character complexity requirements to meet standards like NZISM. For users who have existing but substandard passwords, we redirect them to a "reset password" page on the site and request a stronger password. When they reset their password, we enforce the strength requirement again.
We check for breached passwords by using HaveIBeenPwned data to warn users that their password has been previously breached, and to encourage or enforce them to change their password to a random, unique password. We also take the opportunity to block simple and commonly used passwords.
We address weak encryption and cookie credentials through session cookie cryptographic enhancement to strengthen session management. This overcomes the issues associated with insecure tokens, which leave sessions vulnerable to hijacking. We intercept the session token produced by the server and replace it with a cryptographically secure token. The secure token is used between the user and RedShield, and we map it to the existing session token when communicating from RedShield to the server.
We double up on security layers with second-factor authentication (2FA) shields. Our shields are designed to prevent malicious users from logging in to compromised accounts. They address the issues many organizations have with 2FA due to older applications and insufficient internal resources. Without touching your code, our SMS or Time-based One Time Password (TOTP) 2FA shields require users to provide a code when logging in. Even if an attacker has compromised the username and password, they will not be able to respond to the 2FA challenge.
We can also apply strong transaction authentication through mutual TLS (aka mTLS). mTLS makes sure that both connecting parties are who they say they are by verifying a private cryptographic key, backed up by presenting and accepting their respective TLS certificates. This allows both parties to exchange information over an encrypted TLS connection safely.
