We will be undergoing planned maintenance on Oct 7th 6:00AM UTC / Oct 7th 2:00AM ET

Inspiration

I've always been interested in cybersecurity, but I noticed that most password tools available online give you a colored bar and nothing else. They tell you your password is "medium strength" without explaining why — or what to do about it.

I wanted to build something that actually teaches. A tool where a non-technical person could type their password and walk away understanding entropy, dictionary attacks, and why P@ssw0rd fools nobody. Security education shouldn't require a computer science degree.


What it does

YourPassword is a browser-based password security toolkit with five features:

  • Strength Checker — real-time analysis with per-criterion feedback, entropy in bits, and estimated crack time
  • Password Generator — configurable length and character sets, with one-click copy
  • Passphrase Generator — random word combinations that are easier to remember and harder to crack
  • Breach Check — checks your password against HaveIBeenPwned's database of billions of leaked credentials, using k-anonymity so your password never leaves your device
  • Education Tab — plain-English explanations of how password attacks actually work

How I built it

I used spec-driven development — the core skill this hackathon teaches. Before writing a single line of code, I produced:

  • A scope document defining what was in and out of the project
  • A PRD with user stories and acceptance criteria for each feature
  • A technical specification with architecture decisions made upfront

This process changed how I built. Instead of vibe-coding and figuring things out as I went, I had a clear picture of the finished product before I started. Every feature had a definition of "done."

The app itself is a single HTML file — no frameworks, no build step, no dependencies. Just HTML, CSS, and vanilla JavaScript. The breach check uses the Web Crypto API to compute a SHA-1 hash client-side, then applies the k-anonymity model:

$$H = \text{SHA-1}(\text{password})$$

Only the first 5 characters of $H$ are sent to the HaveIBeenPwned API. The server returns all matching hash suffixes, and the full match is checked locally. The password itself — and even its complete hash — is never transmitted.


Challenges

The breach check and CORS — the HaveIBeenPwned API call worked fine in a standalone HTML file but was blocked by CORS in certain development environments. Understanding why (browser security model, cross-origin requests, the difference between a static file and a served page) was a valuable detour.

Entropy estimation for passphrases — calculating entropy for random passwords is straightforward:

$$E = L \times \log_2(N)$$

where $L$ is the password length and $N$ is the character pool size. But for passphrases, the unit is words, not characters. Each word from a 2048-word list contributes approximately:

$$\log_2(2048) \approx 11 \text{ bits}$$

So a 4-word passphrase has roughly 44 bits of entropy — which sounds less impressive than it is, until you realize how much harder it is to crack than a typical 8-character "complex" password.

Scope discipline — the hardest challenge was deciding what not to build. Dark mode, browser extension, password history, strength comparison mode — all good ideas, all out of scope for v1. The scope document saved me from myself multiple times.


What I learned

  • Planning before building is a skill, not a formality. Writing a PRD forced me to make real decisions upfront instead of discovering them mid-build and backtracking.
  • Single-file architecture is underrated. No build pipeline means no build failures. No dependencies means no dependency hell. For a tool that doesn't need a backend, this was the right call.
  • Privacy can be a feature. The k-anonymity implementation isn't just technically interesting — it's something worth explaining to users. People respond well to transparency about how their data is handled.
  • The spec-driven process produces artifacts you actually reuse. The scope doc, PRD, and technical spec aren't just hackathon deliverables — they're templates I'll use for future projects.

Built With

Share this project:

Updates

Submission history