A transit password-reset endpoint accepts unlimited attempts and returns distinct messages for valid versus invalid accounts. What abuse class should the tester highlight?
Select an answer to reveal the explanation.
Short Explanation
A reset door with no bouncer and a chatty receptionist helps attackers map who is real and hammer accounts. Rate limits and careful, uniform responses close that gap. Recovery flows need the same love as login.
Full Explanation
Account recovery flow abuse from missing rate limits and user-enumeration responses should be highlighted when a transit password-reset endpoint accepts unlimited attempts and returns distinct messages for valid versus invalid accounts. Attackers can both hammer resets (availability/lockout harassment) and harvest which rider accounts exist—compounding credential attacks against the transit identity surface.
Unlimited resets are not “secure design for availability.” CSP gaps on help pages and Kerberos unconstrained delegation are unrelated distractors.
Exam caveat: recovery endpoints need rate limits, uniform responses, and monitoring; enumeration plus no throttling is a common CPTS web auth finding. Avoid locking real riders during testing.
Operational check: confirm differential messages and lack of throttling with minimal probes under RoE, implement generic responses and rate limits/CAPTCHA, alert on reset bursts, and retest the transit recovery API. Recovery and login endpoints deserve the same WAF/rate-limit attention as primary transit APIs because abuse often starts at account lifecycle flows. Enumeration via reset messages accelerates password attacks against transit rider accounts.