Summary: Learn what authentication vulnerabilities (or risks) are, how they emerge and how these issues can affect your organization. You'll also learn about the most common authentication-based vulnerabilities and their implications and best practices to prevent authentication and keep sensitive data safe.
Authentication is the front door to every system you run, but it's also where a large share of breaches begins. According to Statista, more than 1,000 data breaches in 2020 exposed over 155 million records at an average cost of $3.86 million.
What's difficult to know is that more than 82% of breaches were caused by authentication issues through stolen or weak credentials. Most authentication weaknesses are well documented, straightforward to spot once you know the pattern and fixable with changes your team can make.
This is why you need to know and prevent these 11 common authentication vulnerabilities.
Authentication vulnerabilities are issues that affect authentication processes and make websites and applications susceptible to security attacks in which an attacker can masquerade as a legitimate user.
Authentication is a core part of any website or application since it is simply the process of recognizing user identities.
Several common categories of authentication issues can result from vulnerabilities in login credentials, site protection, or even underlying code.
There are several ways through which authentication vulnerabilities can arise, the most common of which are neglecting to address areas of risk, errors in code or logic, and poor user choices which can combine with the previous two. If an application has poor brute-force protection, attackers can take advantage of this to gain access to even well-protected accounts or cheap bulk access to poorly protected ones.
Likewise, if there are logic or coding errors, malicious users may be able to bypass some or all of the authentication process.
Authentication vulnerabilities have serious repercussions, whether it’s because of weak passwords or poor authentication design and implementation.
Malicious users can use these vulnerabilities to get access into systems and user accounts to:
If attackers can illegally pass through the authentication process and gain access to a user account, they can steal sensitive data like names, credit card details, social security numbers (SSNs), medical records and tax IDs. They can also take actions on a user’s behalf, such as initiating financial transactions, deleting data or transferring ownership of resources.
Worse still, attackers can fully control your system or completely shut it down if they find their way into top-level accounts such as admin profiles. Once present, these authentication vulnerabilities can substantially affect your company’s viability and credibility.
You may also face legal consequences with GDPR, CCPA, financial services regulations or other local laws depending on what type of data is breached.
Authentication vulnerabilities, if not properly controlled, can damage a company’s security and its reputation.
Here are 11 of the most common authentication-based vulnerabilities to watch out for:
A brute-force attack works through large numbers of randomly generated or pre-generated combinations of usernames and passwords until one of them works. Password spraying and credential stuffing are variants of the same idea.
If there’s a flawed brute-force protection system such as a flaw in the authentication logic, firewall, or secure shell (SSH) protocol, attackers can hijack login credentials and processes, compromising the security of user credentials.
If the password is predictable, this can lead to vulnerabilities in the authentication process. Predictable usernames can make it easier for attackers to target specific users.
Rather than using a full brute-force attack, the attackers will look for accounts with easy-to-guess passwords, which are used far too often. They’ll try common credentials like "admin," "admin1," and "password1." With no restrictions on weak passwords, even sites protected against brute-force attacks can find themselves compromised.
Username enumeration is not exactly an authentication vulnerability. But, it can make an attacker’s life easier by lowering the cost for other attacks, such as brute-force attacks or weak credential checks.
This process of username enumeration confirms whether or not a username is valid. For example:
In this case, the username is correct, but the password isn’t.
Here, the username is invalid.
The problem with username enumeration is that attackers can tell what usernames are valid. Then, they can try to hack valid user accounts using brute-force techniques without wasting their time and money testing a multitude of invalid account names.
This classic web authentication protocol is easy to implement but it is not without its risks.
HTTP basic authentication is simple, sending a username and password with each request. However, if appropriate security protocols such as TLS session encryption are not used for all communication, the username and password information can be sent in the clear, making it easy for attackers to steal the credentials.
Because the included credentials contain so little context, they can easily be misused in attacks such as cross-site request forgeries (CSRF). Also, because they are included with every single request, modern browsers normally cache this information indefinitely, with minimal ability to "log out" and prevent a local attacker from reusing the credential at some future point.
A vulnerability in the management of session identifiers leads to hijacking of valid authenticated sessions. This is one of the common web vulnerabilities to bypass passwords.
There are several session mismanagement vulnerabilities such as no session timeouts, exposure of session IDs in URLs, session cookies without the Http-Only flag set, and poor session invalidation.
If attackers can seize control of an existing session, they easily get into a system by assuming the identity of an already-authenticated user, bypassing the authentication process entirely.
A "Remember me" or "Keep me logged in" checkbox beneath a login form makes it super easy to stay logged in after closing a session. It generates a cookie that lets you skip the process of logging in.
That can lead to a cookie-based authentication vulnerability if an attacker can predict a cookie or deduce its generation pattern. They can use malicious techniques like brute-force attacks to predict cookies, and cross-site scripting (XSS) to hack user accounts by allowing a malicious server to make use of a legitimate cookie.
If a cookie is poorly designed or protected, attackers may be able to obtain passwords or other sensitive (and legally protected) data such as user addresses or account information from a stored cookie.
SQL injection is an attack vector that uses malicious SQL code input in an unexpected way to manipulate and access a database.
SQL injections can enable attacks on authentication mechanisms by stealing relevant data (such as poorly protected password hashes) from an unprotected database. They can also bypass authentication mechanisms if the injected SQL code is executed by an internal (and already authorized) tool that failed to sufficiently validate external input.
Sometimes, users forget or just want to change their passwords and click the "Forgot password" or "Lost your password" links.
The password reset process poses an authentication vulnerability if an application uses a weak password recovery mechanism such as easy security questions, no CAPTCHAs, or password reset e-mails with overly long or no timeouts.
If the password recovery functionality is flawed, attackers can potentially use brute-force techniques or access to other compromised accounts to gain access to user accounts and credentials that are well-protected under normal circumstances.
While two-factor authentication (2FA) is effective for secure authentication, it can cause serious security issues if not well-implemented.
Attackers can figure out the four- and six-digit 2FA verification codes through SIM swap attacks if they are sent through SMS. Some two-factor authentication is also not truly two-factor; if a user is attempting to access sensitive information on a stolen phone using cached credentials, a "second factor" that sends a message to that same phone adds no additional security.
Two-factor authentication vulnerabilities can also occur if there’s no brute-force protection to lockout an account after a specific number of attempted logins.
Logic vulnerabilities are common in software applications. This occurs as a result of poor coding or design that affects authentication and authorization access, and application functionality.
Flawed application logic can be due to the abuse of functionality, weak security measures, or a skipped step in the verification procedure.
For example, an application can prompt a user to answer a security question the logic deems as something "only the correct person would know." But questions like the user’s birthday or mother’s maiden name are often easy to discover. This vulnerability makes it easy for cyber attackers to bypass authentication and gain illegal access to such accounts.
According to Shred-it 2020 report, up to 31% of C-suite executives reported employee negligence to be the second major cause of their data breaches.
Human error can result in serious authentication vulnerabilities that are far easier to take advantage of than brute-force attacks, SQL injections, and authentication bypasses. This negligence includes actions such as:
While authentication vulnerabilities are easy to identify, they greatly impact cybersecurity. But, you can prevent them from happening.
Here are nine best practices to prevent authentication-based vulnerabilities and keep critical information safe.
Most of the fixes above are engineering work rather than a purchase: better error handling, better cookie flags, better code review.
Where a product earns its place is the privileged end of the list, where credentials are shared, long-lived and attached to accounts that can reach everything. The Delinea Platform vaults those credentials so they are not distributed, grants access just-in-time rather than leaving it standing and records the session so there is a record of who did what.
Start with the list above on your own application, then run it again against the accounts your engineers and services use.