The Attendance App Breach
A district's attendance web app has 12,000 student and staff accounts. Passwords are stored as unsalted SHA-256 hashes. An attacker exploits a SQL injection flaw in a report-export page and downloads the users table, including usernames, roles, and password hashes. The district's database volume is encrypted at rest, and the vendor argues that this protects the hashes. The app also emails temporary passwords in plaintext when a user clicks 'forgot password.' The incident team must decide whether to force a password reset for all accounts, add rate limiting, or both, and how to explain the risk to the school board.
1. Explain why unsalted SHA-256 is a poor choice for 12,000 passwords even though SHA-256 is a strong cryptographic hash. What property is missing, and what should replace it?
Read the worked answer
SHA-256 is strong for integrity, but it is fast by design, which is exactly wrong for password storage. A GPU can test billions of candidate passwords per second against SHA-256. Because the hashes are unsalted, identical passwords produce identical hashes, so cracking one account reveals every account with the same password. An attacker can also precompute rainbow tables for common passwords and match the stolen hashes instantly.
The missing property is per-user salting plus deliberate slowness. Each password should be hashed with a unique random salt using a dedicated password-hashing function such as Argon 2 id, bcrypt, or scrypt, with an appropriately reviewed configuration, with a cost factor tuned to the server. The salt defeats precomputation and makes identical passwords hash differently. Because the current hashes cannot be retroactively salted, the district should migrate on next login and force resets for accounts that do not log in soon.
2. The vendor says encryption at rest protects the password hashes, so no further action is needed. Evaluate this claim in the breach scenario.
Read the worked answer
The claim is false for this incident. Encryption at rest protects the database files if a disk or backup is stolen, but the attacker reached the data through the application's SQL injection flaw. The database engine decrypted the volume for the application, so the attacker received plaintext rows, including the hashes. Encryption at rest did not stop the exfiltration.
Once the hashes leave the district, encryption at rest provides no protection against offline cracking. The relevant defenses are salted, slow password hashing and detection of the injection. Encryption at rest is still useful for lost media, but it is not a substitute for application security or password hashing. The incident team should treat the hashes as compromised.
3. Recommend whether to force a password reset for all 12,000 accounts or only those whose hashes appear cracked, and justify with risk reasoning.
Read the worked answer
Force a reset for all accounts. With unsalted SHA-256, cracking is fast and cheap, and the attacker may crack hashes later without the district observing it. The district cannot reliably know which hashes have been cracked, and it cannot assume staff will not reuse passwords on other systems. Waiting for evidence of cracking gives the attacker time to use recovered credentials.
A full reset is disruptive, but the risk is concentrated in exactly the accounts that control student records. The district can phase it by role, starting with administrators and staff with export privileges, while invalidating all active sessions immediately. It should also fix the SQL injection, add rate limiting and monitoring, stop emailing plaintext temporary passwords, and communicate to the board that the reset is a containment step, not a punishment.