authentication-testing

Authentication Testing (Chinese Version)

When to Use

You need to design security testing or review preparation around identity credentials, authentication flows, failure paths, and lifecycle.
You need to deliver a reviewable initial version when materials are incomplete, and clearly state assumptions, gaps, and Human decisions.
You need to distinguish static security evidence, planned validation, and executed runs.

Default output is Markdown, organized by security risk, evidence, and priority.
When the user requests table, CSV, JSON, or ticket format, retain the same finding fields and evidence status.
Before output enters an automated process, first confirm the schema, enum values, and required fields.

First read prompts/authentication-testing.md, and perform the input audit, coverage checklist, and output contract.
Extract scope, environment, version, roles, data, dependencies, constraints, and available evidence.
Build reviewable scenarios around identity credentials, authentication flows, failure paths, and lifecycle, distinguishing known facts, inferences, and candidate validations.
For each record, write the impact, priority, responsible role, closure conditions, and validation method.
When information is insufficient, deliver a limited initial version, and do not write risk assumptions as vulnerability confirmations or security passes.

Every execution must read prompts/authentication-testing.md.
When evaluation is needed, read evals/eval.yaml and the matching evals/cases/.
Only read references/, examples/, scripts/, or output-formats.md when the directory exists and the task requires it.

Based on the given password, MFA, recovery, or federation mechanisms, build a state diagram of unauthenticated/challenging/authenticated/locked/recovering, and mark creation, rotation, expiration, revocation, and replay rules.
Output an authentication state transition and credential lifecycle table, writing the expected state/token, material observations, and gaps per event; authentication does not replace authorization.
When forming domain candidates, you must read and follow prompts/authentication-testing.md the domain operations and determination process, retaining legitimate controls, evidence gaps, and validation actions item by item.

Only analyze identity credentials, authentication flows, failure paths, and lifecycle; do not log in to systems, do not call real APIs, and do not read credentials.
Do not fabricate vulnerabilities, successful attacks, completed fixes, scan coverage, or security pass conclusions.
When evidence is missing, mark as pending confirmation, blocked, or unassessed, and provide an isolated validation method.
Risk acceptance, exception authorization, and release decisions must be left to Human.

Completed the known, missing, conflicting, stale, out_of_scope, assumptions audit.
Covered authentication, trigger conditions, expected focus points, and evidence status.
Separated facts, inferences, recommendations, information gaps, and Human decisions.
Did not write static findings or dry-runs as real attacks, absence of vulnerabilities, or release approval.

Treating a generalized security review or API contract check as a complete substitute for authentication testing.
List only attack names, without writing the scope of applicability, evidence, expected results, and closure conditions.
When information is insufficient, directly determine that it is safe, or read real credentials for the sake of completeness.

Start from high-impact, hard-to-detect, privilege-sensitive, or data-sensitive paths.
Use sanitized materials, least privilege, isolated environments, and rollback-capable verification recommendations.
Enable another engineer to review each security conclusion based on its source and boundaries.