Preventing weak passwords at registration with privacy-preserving API

Builds a serverless API using mmap and Bloom filters to check passwords against leaked dictionaries without exposing user data, enhancing security at registration.

Hey everyone,

I was recently evaluating some Identity Threat Protection tools for my org and realized something frustrating: users are still creating new accounts with passwords like password123 right now, in 2026. Instead of waiting for these accounts to get breached, I wanted to stop them at the registration page.

So, I built an open-source API that checks passwords against CrackStation’s 64-million human-only leaked password dictionary and others.

The catch? You can't just send plain text passwords to an API.
To solve this, I used k-anonymity (similar to how HaveIBeenPwned handles it):

1. •The client SDK (browser/app) computes a SHA-256 hash locally.
2. •It sends only the first 5 hex characters (the prefix) to the API.
3. •The API looks up all hashes starting with that prefix and returns their suffixes (~60 candidates).
4. •The client compares its suffix locally.

The API, the logs, and the network never see the password.

The Engineering / Infrastructure
I'm a DevOps engineer by trade, so I wanted to make the architecture serverless, ridiculously cheap, and secure by design:

• •Compute: AWS Lambda (Docker, arm64) + FastAPI behind an Edge-optimized API Gateway + CloudFront (Strict TLS 1.3 & SNI enforcement).
• •The Dictionary Problem: You can't load 64 million strings into a Python dict in Lambda. I solved this by building a pipeline that creates a 1.95 GB memory-mapped binary index, an 8 MB offset table, and a 73 MB Bloom filter. Sub-millisecond lookups without blowing up Lambda memory.
• •IaC: The whole stack is provisioned via Terraform with S3 native state locking.
• •AI Metadata: Optionally, it extracts structural metadata locally (length, char classes, entropy) and sends only the metadata to OpenAI for nuanced contextual analysis (e.g., "high entropy, but uses common patterns").

I'd love your feedback / code roasts:
While I can absolutely vouch for the AWS architecture, IAM least-privilege, and Terraform configs, the Python application code and Bloom filter implementation were heavily AI-assisted ("vibe-coded").

If there are any AppSec engineers or Python backend devs here, I’d genuinely welcome your code reviews, PRs, or pointing out edge cases I missed.

• •GitHub Repo (Code, SDKs, & local Docker setup): https://github.com/dcgmechanics/is-your-password-weak
• •Architecture Deep Dive: https://medium.com/@dcgmechanics/your-users-are-still-using-password123-in-2026-here-s-how-i-built-an-api-to-stop-them-d98c2a13c716

Happy to answer any questions about the infrastructure or the k-anonymity flow!