A civic identity portal returns "account not found" for some usernames and "invalid password" for others during login attempts the RoE permits. What finding class should the tester report?
Select an answer to reveal the explanation.
Short Explanation
If the site whispers different messages depending on whether the name exists, it is basically confirming the roster for you. That login difference is classic username enumeration—not a full takeover by itself.
Full Explanation
If a civic identity portal returns 'account not found' for some usernames and 'invalid password' for others during RoE-permitted login attempts, the finding class is username enumeration via response disparity between valid and invalid accounts. That pattern is not cross-site scripting in login markup, not successful privilege escalation to domain administrator, and not by itself an insecure direct object reference on a password-reset token. Exam caveat: timing differences can enumerate users even when messages are identical—test carefully within attempt limits. Operational check: document message pairs or timing evidence with sample usernames that are non-sensitive or synthetic, avoid account lockouts, and recommend uniform responses and rate controls for the municipal identity portal. Document the rationale in the municipal engagement notes so later civic responders know which boundary was honored and which failure modes the rejected options would create for public services. Document the rationale in the municipal engagement notes so later civic responders know which boundary was honored and which failure modes the rejected options would create for public services. Document the rationale in the municipal engagement notes so later civic responders know which boundary was honored and which failure modes the rejected options would create for public services.