Authentication Failures: Following the Whole Sign-In Journey

Authentication Failures is the seventh category in my OWASP Top 10:2025 notes. My first thought was the login form, but the reading covers a much longer journey.

An application needs to establish identity, maintain the resulting session, handle recovery, and end access when appropriate. A weakness in any of those steps can undermine the others.

Automated attempts change the problem

Credential stuffing uses username and password combinations exposed elsewhere to try to access another service. Password reuse makes that possible.

Other automated attacks try to guess credentials. The application needs controls that account for repeated attempts without making it easy for an attacker to lock legitimate users out.

The A07 guidance brings together several responses: multi-factor authentication, detection of suspicious attempts, appropriate limits or delays, and avoiding default credentials.

MFA can greatly reduce the usefulness of a stolen password. Its enrollment, recovery, and fallback paths also need protection. A strong sign-in method loses value if an easier recovery route lets someone take over the same account.

Password policy should support useful behavior

The reading connects password security to length, known-compromised password checks, and support for password managers.

Routine forced changes and complicated character recipes can encourage predictable choices. Current guidance favors evidence-based password rules and changes when there is evidence of compromise, rather than relying on a calendar alone.

Password storage belongs in this picture too. As covered in the earlier Cryptographic Failures post, the application should use a suitable password-hashing scheme instead of storing recoverable passwords. The OWASP Authentication Cheat Sheet connects these controls to the wider authentication flow.

Recovery is another way into the account

Consider a hypothetical service that requires MFA at login but resets access after someone answers a question about the account holder's school.

If that answer is discoverable, the recovery process can become the easier route into the account. The design needs to consider what evidence actually establishes control of the account and how that evidence might be obtained by someone else.

Responses also matter. Login, registration, and recovery screens can accidentally reveal whether an account exists. Consistent wording helps, while response timing and behavior need attention as well.

A successful login creates a session to protect

After login, an application often relies on a session identifier instead of asking for the password with every request. Someone who obtains a usable session identifier may be able to act as the user.

That makes session handling part of authentication security. A maintained session-management facility should generate unpredictable identifiers, renew them when authentication or privileges change, and enforce expiration. Browser cookies need appropriate protections for the application, and session identifiers should stay out of URLs.

Logout needs to invalidate the session at the server. Closing a browser tab is not a reliable substitute. With single sign-on, it is also important to understand which sessions a logout actually ends. The Session Management Cheat Sheet provides the detailed controls behind these points.

Questions for my notes

Are there alternate login or recovery routes with weaker checks?
How are automated attempts detected and limited?
What happens if a user loses their MFA method?
When are session identifiers changed and invalidated?
Does logout end the access the user expects it to end?
Are credentials and tokens checked for the service and purpose they were issued for?

My takeaway

Authentication makes more sense to me as a complete account-access process. The login form is one step, and recovery, session handling, and logout need to support the same security expectations.

The next category examines another kind of trust: whether software and data should be accepted as authentic and intact.

Sources and further reading