By Garrett Kohlrusch | GK Data LLC
A password can be long, unique, and stored correctly while the account around it remains easy to take over. The reason is simple: authentication is a workflow, not one field on a login form.
Recovery links, MFA enrollment, remembered devices, active sessions, email changes, support processes, and authorization decisions all extend the trust boundary. Security testing has to follow those paths, because that is where one compromised credential can become persistent access or broader business impact.
A password answers only one question
A login form asks whether the person presenting a secret should be allowed to start a session. It does not prove that the same person should be able to reset MFA, change an account email, view another customer’s data, keep old sessions alive after a reset, or call a sensitive administrative function.
Those are separate decisions. When applications collapse them into “the user is logged in,” the password becomes a master key it was never designed to be.
Five trust boundaries worth testing
1. Account recovery
The reset flow should not be weaker than the login it replaces. Test token lifetime, single use, account enumeration, rate limits, email-change behavior, and whether recovery invalidates older links and active sessions.
2. MFA enrollment and removal
MFA helps only if an attacker cannot disable it using the session they just stole. Sensitive changes should require recent reauthentication, notify the account owner, and provide a controlled recovery path. Manually entered one-time codes improve security but are still phishable. NIST distinguishes them from phishing-resistant cryptographic authentication such as properly implemented passkeys and security keys.
3. Session lifecycle
Applications should define when sessions expire and what events revoke them. A password change that leaves every existing browser session active may not remove an attacker. The same applies to account recovery, privilege changes, employee termination, and suspected compromise.
4. Authorization after login
Authentication establishes an identity. Authorization decides what that identity may do. Every sensitive object and function still needs a server-side check. Changing a user ID, organization ID, HTTP method, or API route should not expose another customer’s records or an administrative action.
5. Support and operational workflows
A well-built application can still be undermined by a support process that accepts weak identity proof. Review who can reset an account, change an email, issue an invitation, or approve a financial action, and what independent evidence is required.
A practical authentication test
A useful assessment does more than try common passwords. It uses controlled accounts and asks concrete questions:
- Can one account learn whether another email address is registered?
- Does a reset token expire, become invalid after use, and bind to the intended account?
- Does changing a password revoke sessions and refresh tokens that should no longer be trusted?
- Does changing an email address or MFA method require recent authentication?
- Can a normal user call administrative API functions or access another tenant’s objects?
- Are recovery and security events visible in logs and communicated to the account owner?
What good remediation looks like
- Offer long passwords and password-manager compatibility without arbitrary composition rituals.
- Block commonly compromised values and rate-limit abusive authentication attempts.
- Use phishing-resistant authentication for administrators and other high-impact accounts where feasible.
- Require reauthentication for security-sensitive account changes.
- Revoke sessions predictably after resets, password changes, and suspected compromise.
- Enforce authorization at every server-side object and function boundary.
- Log recovery, enrollment, session, and privilege events with enough context to investigate them.
The current NIST Digital Identity Guidelines provide a useful technical baseline for authenticator and phishing-resistance decisions.
How GK Data approaches identity testing
Within an authorized web or API scope, GK Data can evaluate authentication flows, recovery behavior, session controls, role boundaries, and related business logic. Reconnaissance and automation help map endpoints and compare responses. Findings are manually reproduced and tied to a specific unauthorized outcome before they reach the report.
Review the Web Application and API Penetration Testing service or send the application and roles you need tested.