Authentication Failures: How Testers Try to Compromise User Accounts

Attackers do not always need a complex technical vulnerability to compromise a web application.

Sometimes, a valid username and password are far more useful.

If an attacker can gain access to a genuine account, their activity may initially appear to be normal user behaviour. Depending on the account and application, they could:

• Access sensitive information
• Download documents
• Change payment details
• Place orders
• Impersonate the user
• Access other customer accounts
• Perform administrative actions
• Change security settings
• Establish persistent access

This is why authentication testing needs to cover more than weak passwords.

A web application penetration test should examine the complete authentication process, including login, account recovery, multi-factor authentication, session creation and protections against automated attacks.

The central question is:

How difficult would it be for an attacker to obtain, guess, reset or reuse a customer’s login credentials?

What is an authentication failure?

Authentication is the process an application uses to decide whether somebody really is the person they claim to be.

An authentication failure occurs when the application does not reliably verify that identity or protect the session created after verification.

Weaknesses can appear within:

• Login forms
• APIs
• Mobile applications
• Single sign-on
• Password-reset processes
• MFA workflows
• Trusted-device features
• Session management
• Account registration
• Support-assisted recovery
• Administrative portals

Authentication should be treated as a complete lifecycle, not simply a username and password form.

A secure login page provides limited protection if an attacker can bypass it through an older API, manipulate the password-reset process or reuse an authenticated session.

The tester needs to understand every route into the account and how those routes interact.

Mapping every authentication route

Before testing individual controls, a penetration tester should identify all the ways a user can obtain access.

These may include:

• The main website login
• Mobile application APIs
• Administrative interfaces
• Customer and partner portals
• Single sign-on
• Social login
• Legacy API endpoints
• Password recovery
• Invitation and activation links
• Remembered devices
• Support-assisted recovery

The strongest login process can be undermined by a less visible route that applies weaker controls.

For example, the main website might enforce MFA, rate limiting and modern session handling, while an older mobile API accepts only a username and password.

A tester should also identify the available account types.

These might include:

• Customers
• Employees
• Support staff
• Partners
• Suppliers
• Application administrators
• System administrators

Different roles may use separate login portals or authentication methods. Administrative accounts may also have access to functions that make even a small authentication weakness much more significant.

Username enumeration

Username enumeration occurs when an application reveals whether an account exists.

This may happen through messages such as:

• “Incorrect password”
• “Account not found”
• “This email address is already registered”
• “A reset email has been sent”
• “This account is locked”

The differences may also be less obvious.

A valid and invalid username might produce:

• Different HTTP status codes
• Different response lengths
• Different page content
• Different response times
• Different API error codes
• Different password-reset behaviour
• Different redirects

Username enumeration does not normally compromise an account by itself. It gives the attacker a reliable list of valid users.

That list can then support:

• Password spraying
• Credential stuffing
• Targeted phishing
• Social engineering
• Support impersonation
• Attacks against high-value users

Testing should examine more than the login page.

Enumeration may appear in:

• Registration
• Password reset
• Account activation
• MFA enrolment
• Invitation acceptance
• API responses
• Support portals

For example, the login form may return a generic message for every failed attempt while the password-reset API reveals whether the supplied email address exists.

Applications should normally return consistent responses that do not unnecessarily confirm whether an account is registered.

Care is still needed when designing those responses. Telling every user that an email has been sent is useful only if the application behaves securely behind the scenes and does not reveal the result through another response or timing difference.

Password spraying

Password spraying involves trying a small number of commonly used passwords against many accounts.

This differs from repeatedly guessing passwords for one user.

A traditional password attack might submit hundreds of guesses against a single account. That is likely to trigger per-account lockout controls.

A password-spraying attack instead tries one likely password against a large list of known usernames. The attacker may wait before trying the next password, reducing the likelihood of triggering simple lockout thresholds.

A penetration tester should assess whether the application uses protections such as:

• Rate limiting
• Progressive delays
• IP and device monitoring
• Detection across multiple accounts
• Multi-factor authentication
• Risk-based authentication
• Alerts for unusual login patterns
• Detection of common or compromised passwords

Controls need to consider the overall pattern rather than viewing each account independently.

If 500 different accounts each receive one failed attempt using the same password from related infrastructure, that may indicate a coordinated attack even though no single account has reached its lockout threshold.

Testing must be controlled carefully. Agreed test accounts, attempt limits and testing windows should be used to avoid locking out genuine users or causing unnecessary alerts.

Credential stuffing

Credential stuffing uses username and password combinations obtained from unrelated data breaches.

It works because users often reuse credentials across different services.

The distinction is:

• Password spraying tests a small number of likely passwords against many accounts
• Credential stuffing tests username and password combinations previously exposed elsewhere

A user may choose a long and technically strong password, but if they reuse it on several websites, a breach of one service can place their other accounts at risk.

An application may be particularly exposed to credential stuffing if it:

• Does not enforce MFA
• Lacks effective automated-attack detection
• Permits large numbers of distributed login attempts
• Does not identify compromised credentials
• Provides clear signs of successful authentication
• Uses predictable login endpoints across several interfaces

A strong password policy cannot prevent a user from reusing an otherwise compliant password elsewhere.

Organisations can reduce this risk through MFA, compromised-password checks, effective monitoring and controls that identify unusual authentication patterns.

Weak account-lockout controls

Account lockout can slow password attacks, but poorly designed controls may be ineffective or create additional problems.

Potential weaknesses include:

• No limit on failed attempts
• Limits applied only in the browser
• Limits that do not cover API endpoints
• Controls based only on source IP addresses
• Counters that reset too quickly
• Username variations bypassing the limit
• Different limits across authentication routes
• Unlimited attempts against MFA codes
• Lockout applied to only one session

A tester may determine whether attempts can be distributed across:

• Multiple IP addresses
• Multiple sessions
• Different endpoints
• Mobile and web interfaces
• Username variations
• Password and MFA stages

An application might block one browser after ten failed logins while continuing to accept unlimited requests through its API.

IP-based limits are useful but should not be the only protection. Attackers can distribute attempts across many addresses, while genuine users may share the same corporate or mobile network address.

Effective controls usually combine account, device, network and behavioural signals.

When lockout becomes a denial-of-service risk

Permanently locking an account after a small number of failed attempts may stop password guessing, but it can also give attackers an easy way to deny access to legitimate users.

This could be particularly disruptive for:

• Administrators
• Customer-service accounts
• Emergency accounts
• High-value customers
• Shared operational accounts

If the application reveals valid usernames, an attacker could deliberately submit incorrect passwords against each one and lock out a large number of users.

Better protections may combine:

• Progressive delays
• Temporary restrictions
• Risk-based challenges
• MFA
• Alerts
• Monitoring across multiple accounts
• Secure recovery options

The objective is to make automated attacks impractical without giving attackers a simple mechanism for disabling accounts.

Shared accounts should generally be avoided because they make activity harder to attribute and recovery more disruptive. If a shared account is locked or compromised, several people may lose access simultaneously.

Multi-factor authentication bypass

MFA significantly reduces the risk of account takeover, particularly where passwords have been stolen or reused.

However, MFA must be enforced throughout the application.

A penetration test should determine whether an attacker can:

• Access protected pages after completing only the password stage
• Call an API using a partially authenticated session
• Skip or reorder authentication steps
• Use a recovery process that does not require equivalent verification
• Disable or replace MFA without reauthentication
• Reuse a trusted-device token
• Access an older login route without MFA
• Reuse an already authenticated session

MFA bypass usually does not require an attacker to break the cryptography or predict a one-time code.

The weakness is often caused by inconsistent workflow enforcement. The application may display an MFA prompt but issue a session or token that already has access to protected functions.

Phishing-resistant methods such as properly implemented passkeys and security keys provide strong protection, but the application must still manage its authentication states and sessions correctly.

Seeing an MFA screen is not enough. Every protected function needs to verify that the complete authentication process was satisfied.

Insecure password-reset processes

Password recovery is an alternative authentication mechanism.

It must therefore be protected as carefully as the normal login process.

Potential weaknesses include:

• Predictable reset tokens
• Tokens that remain valid for too long
• Tokens that can be reused
• Failure to invalidate older tokens
• Reset links exposed through URLs, logs or analytics
• Links generated using an attacker-controlled host
• Tokens not tied to a specific user
• Email addresses changed without verification
• Password reset automatically creating a fully authenticated session
• Existing sessions remaining active after reset

The guiding principle should be:

A password-reset process should not provide an easier route into an account than the normal login process.

Reset tokens need sufficient randomness and a short, appropriate validity period. They should be single-use and tied to the intended account.

Requesting a new reset link should normally invalidate earlier links. Otherwise, an old email containing a valid token may remain useful long after the user believes the recovery process has finished.

Applications should also be careful when constructing reset links. If an attacker can influence the hostname placed into the email, the legitimate user may be directed to an attacker-controlled site that captures the token.

After a successful password reset, the application should consider whether existing sessions and trusted devices need to be revoked. Leaving an attacker’s existing session active may allow them to retain access despite the user changing the password.

Account recovery and support processes

Technical authentication controls can be undermined by weak operational procedures.

An attacker may contact support and attempt to persuade staff to:

• Change the registered email address
• Remove MFA
• Issue a temporary password
• Add a new telephone number
• Unlock an account
• Share account information

This is particularly dangerous when support staff are under pressure to resolve problems quickly.

Authentication questions based on publicly available information provide limited protection. Birth dates, addresses, employers and family information may be available through social media, data breaches or public records.

Organisations should define clear identity-verification procedures for high-risk account changes.

The level of verification should reflect the account’s sensitivity and authority. Removing MFA from a privileged administrator should require much stronger evidence than assisting a user with a low-risk public forum account.

Support staff should also understand which security controls they are not authorised to bypass, even when a caller sounds convincing or claims that the issue is urgent.

Session fixation

After a successful login, the application normally issues a session identifier representing the authenticated user.

In a session-fixation attack:

1. The attacker obtains or sets a known session identifier.
2. The victim authenticates using that session.
3. The application does not replace the identifier.
4. The attacker reuses it to access the authenticated session.

The application should regenerate the session identifier when the user moves from one security state to another.

This may include:

• After login
• After MFA completion
• After privilege changes
• After account recovery
• When moving from anonymous to authenticated functionality

A new authenticated session should be unpredictable and unknown to any other party.

Simply adding an authenticated flag to an existing anonymous session can be unsafe if an attacker already knows or controls its identifier.

Session handling after authentication

Compromising a password is not the only way to access an account. Attackers may steal or reuse an existing authenticated session.

Testing should assess:

• Cookie security attributes
• Session identifier unpredictability
• Session expiry
• Idle timeouts
• Absolute session lifetime
• Logout invalidation
• Concurrent session management
• Session rotation
• Revocation after password changes
• Revocation after MFA changes
• Protection of refresh tokens
• Whether users can view and terminate sessions

Cookies used for authentication should be protected appropriately against interception and unnecessary browser access.

Logout should invalidate the session on the server. Removing a cookie from the browser is insufficient if the same token remains valid when submitted again.

Long-lived sessions and refresh tokens need particular care because they may provide continued access even after the short-lived access token expires.

Users should ideally be able to see where their account is active and revoke sessions they do not recognise.

MFA cannot protect an account if the attacker has already obtained a valid post-authentication session.

Authentication weaknesses in APIs

Modern applications often perform authentication through APIs behind the visible interface.

A secure-looking login page may depend on endpoints that:

• Lack rate limiting
• Reveal whether an account exists
• Accept authentication without MFA
• Issue excessively long-lived tokens
• Fail to revoke refresh tokens
• Support outdated authentication methods
• Return excessive information in error responses

Testing should compare the protections applied to:

• Web interfaces
• Mobile application APIs
• REST APIs
• GraphQL endpoints
• Legacy API versions
• Administrative APIs

Security controls must be enforced by the server, not simply by the visible interface.

Disabling a login button after several failed attempts does not provide meaningful protection if an attacker can send requests directly to the API.

The same applies to MFA. The browser may refuse to display the customer dashboard until the second factor has been completed, but the API must independently reject the partially authenticated token.

Single sign-on and alternative identity providers

When an application uses single sign-on, authentication may involve both the application and an external identity provider.

A reputable identity provider can provide strong authentication capabilities, but its use does not automatically secure every part of the application.

Testing should consider:

• Whether local accounts bypass SSO requirements
• Whether MFA is enforced consistently
• Whether authentication tokens are validated correctly
• Whether the issuer and audience are checked
• Whether expired or replayed tokens are accepted
• Whether account linking can associate the wrong identity
• Whether obsolete authentication routes remain accessible
• Whether the application protects its own sessions

The application should verify that tokens were issued by the expected identity provider, intended for the correct service and remain within their validity period.

Account linking also needs careful design. An attacker should not be able to register a local account and then link it to another person’s SSO identity using an unverified email address.

Local emergency or administrative accounts may be necessary, but they should be tightly controlled and should not become an unmonitored way around the main security policy.

How a penetration tester assesses authentication

Authentication testing should follow a structured process using agreed accounts and attempt limits.

Identify accounts and roles

The tester establishes which customer, employee, support and administrative account types exist.

Different roles may use different authentication routes and have different levels of access.

Map every authentication workflow

The tester documents:

• Login
• SSO
• MFA
• Password recovery
• Account registration
• Invitations
• Activation
• Trusted-device features
• Support-assisted recovery

This helps identify alternative routes that may apply weaker controls.

Compare valid and invalid responses

The tester checks for username enumeration through:

• Response content
• Timing
• HTTP status codes
• Response length
• API behaviour
• Email and recovery workflows

Subtle but reliable differences may still provide useful information to an attacker.

Assess automated-attack protections

Rate limits, progressive delays, lockout behaviour and detection are reviewed across different accounts and endpoints.

Testing should establish whether controls consider distributed attempts rather than only repeated failures from one browser or address.

Examine recovery routes

The assessment reviews the generation, validation, expiry, reuse and invalidation of recovery tokens.

It should also consider what happens to existing sessions and MFA after recovery.

Compare authentication states

Sessions and tokens can be examined:

• Before login
• After password acceptance
• After MFA
• After privilege changes
• During account recovery

This helps determine whether partially authenticated states are properly restricted.

Test the session lifecycle

The tester assesses:

• Session rotation
• Fixation
• Expiry
• Logout
• Revocation
• Password changes
• MFA changes

The objective is to establish whether a stolen or previously issued session can remain useful.

Validate every interface

The same controls should apply consistently to websites, APIs, mobile services and administrative portals.

Testing should use authorised accounts and safe techniques to avoid affecting legitimate users.

Why automated scanners struggle with authentication

Automated tools can identify some cookie and configuration weaknesses.

However, meaningful authentication testing requires an understanding of:

• Account roles
• Intended user journeys
• Different authentication states
• Recovery processes
• MFA behaviour
• API interactions
• Lockout thresholds
• Business risk
• Links between separate weaknesses

A scanner might identify a missing cookie attribute while completely missing a password-reset process that provides a route around MFA.

It may also fail to understand that the mobile API uses different rate limiting from the website or that a trusted-device token survives a password change.

Manual testing allows the tester to compare workflows, interpret application behaviour and assess whether several weaknesses can be combined.

Chaining authentication weaknesses

Authentication findings should not always be considered in isolation.

For example:

1. Username enumeration identifies valid administrator accounts.
2. Weak distributed rate limiting permits password spraying.
3. An alternative API endpoint does not enforce MFA.
4. Existing sessions remain active after the password is changed.

Each weakness may appear limited when viewed separately.

Combined, they could create a practical route to account compromise and allow the attacker to retain access after the legitimate user attempts to recover the account.

Another attack path might combine a weak recovery process with trusted-device functionality. The attacker resets the password, registers their device as trusted and retains access even after the user regains control.

Experienced manual analysis is needed to understand these relationships.

The key question is not simply whether each individual control could be improved. It is whether the weaknesses combine into a realistic route to compromise.

What could account compromise mean for the business?

Successful account compromise could allow an attacker to:

• Access customer or employee information
• Download confidential documents
• Change contact or payment details
• Commit fraud
• Impersonate legitimate users
• Access administrative functions
• Compromise other accounts
• Damage or delete information
• Use the application to attack customers

The consequences may include:

• Personal data breaches
• Financial loss
• Service disruption
• Regulatory exposure
• Contractual consequences
• Reputational damage
• Loss of customer confidence

The impact depends heavily on the compromised account.

A customer account might expose one person’s information. A support account could provide access to many customers. An administrator account could affect the entire service.

Account compromise can also be difficult to identify because the attacker may initially use valid credentials and ordinary application functions.

How can organisations strengthen authentication?

Practical measures include:

• Require MFA for privileged and sensitive accounts
• Prefer phishing-resistant authentication where practical
• Use generic authentication and recovery responses
• Apply rate limiting across accounts, addresses, devices and endpoints
• Monitor for password spraying and credential stuffing
• Avoid lockout controls that create denial-of-service weaknesses
• Generate strong, single-use reset tokens
• Set short recovery-token expiry periods
• Invalidate existing sessions after password or MFA changes
• Regenerate session identifiers after authentication
• Protect cookies appropriately
• Provide active-session visibility and revocation
• Secure APIs to the same standard as the web interface
• Remove obsolete authentication routes
• Require strong verification for support-assisted recovery
• Log and alert on unusual authentication activity
• Test authentication controls after significant changes

Controls should be applied consistently across the complete application estate.

Adding MFA to the main web login is valuable, but it should not leave an older API or support portal protected only by a password.

Monitoring should also consider the behaviour of the whole user population. A single failed login may be unremarkable, while the same password being tried against hundreds of accounts indicates a very different risk.

Authentication is a complete journey

Authentication security is not determined solely by the password policy or the presence of an MFA prompt.

A meaningful assessment should establish:

• Whether valid users can be identified
• Whether automated password attacks are practical
• Whether MFA is consistently enforced
• Whether account recovery is secure
• Whether sessions are created and invalidated correctly
• Whether every interface applies equivalent controls
• Whether separate weaknesses can be combined

The key question is not simply whether legitimate users can log in securely.

It is whether an attacker can find another route into their accounts.

How well does your application protect customer and administrator accounts?

Plainsight Security assesses login controls, password recovery, MFA, APIs and session handling as part of a manual web application penetration test. Contact us to discuss your requirements.