The course finale. Students review the fictional club app's accounts, data and system, choose the fix that really closes each of seven weaknesses (wrong fixes explain why they fall short), collect three flags, then repeat on the launch-day copy with every fix right first time (AC9TDI10P13 node 1, AC9TDI10P14 node 3). Defensive throughout. A 5E mission lesson.
Load these into Waypoints Prepare: choose Load URL and paste the copied address, or download the file and import it. In Prepare, the worksheet's Teacher edition shows the answers; the student copy hides them.
SlidesDownload Present from the browser, or export to PowerPoint or PDF.
WorksheetDownload Print the student copy; the Teacher edition has the answers.
Students will be able to
I can review a system's accounts, data and setup for weaknesses.
I can choose a fix that really closes a weakness, and say why others don't.
I can protect stored passwords with hashing and collect only what's needed.
Timing
Engage and Explore 15 min · Explain 8 min · Elaborate 10 min · Evaluate 7 min
Before class
Try the board yourself. The club app is made up.
Flags (for you, not students): Accounts WP{unique-and-mfa}, Data WP{only-what-we-need}, System WP{patched-and-encrypted}. Each appears on the board when its section is fully fixed, so the flags reward the fixing; they aren't puzzles.
The one idea: a review checks every part of a system and picks fixes by what they actually stop.
Years 7–8 classes can do this lesson after the first unit: the Data and System sections then lean on your explanation of hashing and HTTPS.
Extension: picoCTF (Carnegie Mellon) has free CTF practice for school students; check its account and age requirements, and your school's policy, before recommending it.
Running the lesson
Engage: ask what a security team is for.
Explore: ask which wrong fix sounded most convincing, and why it falls short.
Explain: ask which lesson of the course each flag comes from.
Elaborate: ask students to say the reason for each fix aloud before clicking.
Evaluate: discuss what should happen each time the app gets a new feature.
The hard part (on purpose)
Students click fixes until one works. The launch-day copy needs every fix right first time, so the reasoning matters.
When students get stuck
What you will see
A question to ask
The fix
A student picks 'Add a ! to the end of it'.
If the old password leaked, what would someone try first?
Small changes to a leaked password are first on the list: use a unique passphrase.
A student picks hashing to fix the missing HTTPS.
Is the password travelling or stored at this point?
HTTPS on the way, hashing in storage.
Answers to the checks
Engage: why review it yourself?: Why does a security team review its own app before it launches? To find and fix them first. Fixing before launch is cheaper and nobody's data is exposed.
Explore: the review: Inspect every part of the club app and fix all seven weaknesses.
Accounts: unique passphrase and a security key. Data: only what's needed, salted hashes and a real notice. System: HTTPS and an update from the real source.
Accounts: Flag 1: the Accounts section, once both its weaknesses are fixed, shows a flag. Type it. A flag (the exact answer is in the teacher notes) A unique passphrase stops a leak elsewhere opening this account (Passwords); a security key stops a stolen or phished password being enough (Second factors).
Data: Flag 2: the Data section's flag. Type it. A flag (the exact answer is in the teacher notes) Collect only what's needed (footprint, APP 3), store salted hashes so a copied database gives away no passwords (APP 11), and tell members what and why (APP 5).
System: Flag 3: the System section's flag. Type it. A flag (the exact answer is in the teacher notes) HTTPS protects data on the way (threat model); updating the add-on from its real source closes a supply-chain weakness.
Elaborate: launch day: The launch-day copy has the same seven weaknesses. Fix every one, choosing the right fix first time.
Seven right first time: the club app is ready to launch.
Keeping it safe: After launch, which habit keeps the club app safe longest? Review it again whenever it changes, and install updates Security isn't done once: every new feature adds points to the threat model, and updates fix flaws found later.
Solutions
One possible solution for each task. Other correct programs are fine.
Elaborate: launch day
Open task: any program that does what the step asks.
Stretch and support
Stretch: Add one new feature to the club app (events sign-up, say) and write its threat model and privacy notice.
Support: The course's idea cards beside the board: passwords, MFA, footprint, threat model, kinds of weakness, APPs.
Exit ticket
Pick one weakness from the review: what was it, what fixed it, and why did one of the wrong fixes fall short?
For example: passwords stored as typed; store salted hashes; renaming the column still leaves every password readable.
What each step is for
Engage: why review it yourself?: Committing to why a team reviews its own system frames the finale: find and fix weaknesses before launch, defensively.
Explore: the review: Students apply every lesson of the course to one system, and the wrong fixes explain why they fall short.
Explain: the flags: Each flag marks a section made safe; the explain for each names the course idea behind it.
Elaborate: launch day: The same review with no second tries: every fix must be right first time, showing the course's ideas are secure.
Where it leads
End of the course. The Security and privacy course (Years 9–10) goes deeper into how sign-in, hashing and keys work, and has its own capture the flag.