A municipal app stores unsalted legacy password hashes. Why does that matter for offline attacks?
Select an answer to reveal the explanation.
Short Explanation
Unsalted legacy hashes are like using the same cheap padlock on every locker—crack one pattern and the rest fall faster. Good storage slows thieves; weak storage hands them a head start. That’s why hash hygiene shows up in real assessments.
Full Explanation
A municipal app that stores unsalted legacy password hashes matters because poor hash hygiene—legacy algorithms and missing salts—makes offline cracking faster and more likely to succeed once the hash store is obtained under authorization. Unsalted legacy formats enable precomputation and rapid candidate testing that modern salted slow hashes are designed to frustrate. Preferring unsalted hashes to simplify password resets is a convenience argument that ignores credential-at-rest risk for citizen and staff accounts. Claiming hash storage quality only affects online spraying misses the entire offline analysis path that often follows database or backup exposure. Treating any hash format as equally resistant once stored in a database erases algorithm and salting differences that dominate real cracking cost. Exam caveat: report the storage weakness as a systemic control failure, not only as “we cracked one user.” Operational check: identify algorithm and salt presence from authorized samples, redact secrets in the main body, and recommend migration to a modern salted slow hash with a forced rotation plan for the municipal app. In municipal operations, record the rationale in the engagement notes so future testers and city defenders understand which approach was chosen and which failure modes the rejected options would create for civic services.