February 9, 2026
Auth Wars: The Disclaimer Strikes Back
Show HN: Minimal NIST/OWASP-compliant auth implementation for Cloudflare Workers
DIY login guide drops; fans praise the warning label, skeptics cry AI vibes and compliance bingo
TLDR: A developer dropped a standards-following demo login system with a big “not for production—use another service” warning. Comments split: fans praise the transparency and teaching value, while skeptics ask who it’s for, suspect AI vibes, and mock the compliance buzzword parade—raising the risk of copy‑paste security gone wrong.
A new open-source demo just landed: a from-scratch login system for Cloudflare apps that follows official security playbooks (think government and industry rulebooks like NIST and OWASP), with proper password handling, short-lived tokens, strict cookies, and 250+ tests. The kicker? A giant, bold warning: this is for learning, not real products—use another service instead. That warning became the star. Commenter TheTaytay cheered the honesty and said the label should be standard issue. But the skeptic squad arrived fast. usefulposter demanded, “Who is this for?” and even wondered if an AI wrote it, asking to see the prompts. They dropped Brandolini’s law—the idea that debunking takes more work than writing—as a side-eye at compliance-heavy tutorials. Cue the jokes: readers riffed on “compliance bingo” (NIST! OWASP! FIPS! PCI!), and the classic internet mantra resurfaced: “never roll your own auth.” Fans countered that this repo is a safe classroom, not a product—showing how the sausage is made without pretending it’s a full meal. The showdown boiled down to education vs. production: empowering walkthrough or security theater waiting to be copy‑pasted? Either way, a modest demo turned into a spicy trust-and-safety debate.
Key Points
- •An educational, standards-aligned auth reference for Cloudflare Workers implements PBKDF2-SHA384, JWT dual tokens, strict cookies, and security headers.
- •Design decisions map to NIST SP 800-63B/800-132, OWASP ASVS, and RFC 8725; 250+ tests cover attack vectors and edge cases.
- •Session model uses server-side tracking with sliding expiration and a max of three active sessions per user.
- •Middleware enforces automatic refresh, HS256 algorithm pinning, and typ claim validation; input validation uses Zod with length-only password policy.
- •A production roadmap lists critical additions (rate limiting, lockout, password change, breached-password checks) and high/medium priorities (CSRF, token rotation, aud claims, logging, CSP nonces, TOTP MFA, WebAuthn).