dumb-password-rules: a catalogue of bad password policies, built with Eleventy

What dumb-password-rules actually is, and who it is for

The repository describes itself as "a compilation of sites with dumb password rules". That is the whole product: a website at dumbpasswordrules.com that lists real services whose password policies are counterproductive, plus a bot that posts random rules to Mastodon and Bluesky. It is a documentation project with a build pipeline attached, not a library, not a validator and not a service you call at runtime.

The audience follows from that. Security engineers use it as a source of concrete examples when arguing against a policy inside their own organisation, because a screenshot of a real bank rejecting a 40-character passphrase lands harder than a paragraph about entropy. Writers and trainers use it as raw material. Contributors who enjoy collecting absurd requirements use it as a place to publish them. Developers looking for something to import into their signup form will find nothing here, and that is the most common misreading of the name.

The Eleventy pipeline behind the catalogue

The top-level layout makes the mechanism visible: .eleventy.js, postcss.config.js, tailwind.config.js, vercel.json, a src directory and a package.json whose scripts drive the build. Eleventy renders the templates, Tailwind produces the stylesheet, and the output lands in _site, which is what gets deployed. The primary language listed for the repository is Nunjucks, the templating language Eleventy uses for the page layouts.

The dependency list is short and entirely build-time: @11ty/eleventy, @11ty/eleventy-img, tailwindcss with the aspect-ratio, line-clamp and typography plugins, alpinejs, markdown-it, js-yaml, esbuild, html-minifier, postcss, autoprefixer and concurrently. Nothing in that list ships to a visitor's browser as a runtime framework except Alpine, which is a small client-side library for the interactive bits. The data flow is therefore one-directional: a contributor adds or edits an entry, the build turns it into static HTML and a compiled Tailwind stylesheet, and Vercel serves the result. There is no database, no API and no server-side logic to reason about when you add an entry.

That architecture is a deliberate trade-off. A static catalogue is cheap to host and hard to take down by accident, which suits a project that is essentially a long-lived archive. The cost is that anything dynamic, such as voting on entries, user submissions through a form, or searching by rule type, has to be bolted on separately or done at build time.

Installing the site locally and adding your first entry

The README does not spell out a local setup, but package.json does. The scripts are named serve and build, and both invoke binaries from node_modules directly rather than relying on a globally installed Eleventy or Tailwind. To run the site on your machine, install the dependencies and start the development server:

npm install
npm run serve

The serve script runs Eleventy with --serve and Tailwind with --watch concurrently, so template edits and style edits both rebuild while the process stays up. Eleventy prints the local address it is serving on, which is the page you open in a browser.

For a production build, the build script runs Eleventy and then Tailwind with --postcss --minify, writing the compiled stylesheet into _site/static/styles/tailwind.css:

npm run build

After that command, _site contains the deployable output. If you want to contribute a rule rather than run the site, the README points at CONTRIBUTING.md for the details and offers a lower-effort path for people who do not use GitHub: message the maintainer on Mastodon with the site name, a link to the page carrying the offending rule, a screenshot, and a written description of the rule. That four-item list is the submission format, and it is worth matching it exactly if you go that route.

Where the project is thin: submission rules and review

The README is generous about how to submit and silent about what happens next. It does not state an acceptance standard, a review timeline, or what counts as a rule too mild to include. The contributing document is referenced twice but its contents are not reproduced, so anyone deciding whether a particular policy qualifies has to read it in the repository rather than in the README.

There is also no documented rollback or correction process. If a listed site fixes its policy, the README does not describe how an entry is removed or marked as resolved, and the repository has no releases to point at for a changelog. For a catalogue whose value depends on entries still being true, that gap matters more than it would in a code library. A reader who wants to check whether an entry is current has to open the linked page themselves.

The evidence standard is another soft spot. A screenshot and a written description are enough to submit, which keeps the barrier low but means entries are only as reliable as the person who filed them. Screenshots go stale when a signup form is redesigned, and the project does not describe any periodic re-verification.

Alternatives: a catalogue of failures versus enforceable guidance

The natural comparison is NIST SP 800-63B, the US federal guideline on digital identity, whose password section is widely cited for recommending length over composition rules and for advising against forced periodic rotation. The difference in approach is fundamental. NIST publishes requirements that an auditor can hold you to; dumb-password-rules publishes examples that a colleague can be embarrassed by. One is normative, the other is illustrative.

OWASP's authentication guidance occupies similar ground to NIST: it is a set of recommendations maintained by a security community, written to be applied. Neither alternative is a website you browse for entertainment, and neither will hand you a screenshot of a specific airline rejecting a password because it contains a space. If your goal is to change a policy, the guideline gives you the argument and this catalogue gives you the evidence, and they are more useful together than either is alone.

If what you actually want is a game about password rules, the search terms around this project suggest people arrive looking for that too. This repository is not that. It is a record of real policies, and the entries are meant to be read as documentation rather than played.

Licence, maintenance and the cost of keeping entries honest

The repository is MIT licensed, which is permissive: it allows reuse, modification and redistribution provided the copyright notice and licence text are kept. For a catalogue of factual entries and site code, that removes most friction if you want to mirror the content or reuse the Eleventy setup for a similar project. It is not legal advice, and anyone republishing screenshots of third-party signup pages should think about the rights in those images separately from the code licence, since MIT covers the repository's own contents and not the material contributors submitted.

The last push to the default branch was on 2026-09-08, a few weeks before this writing, and the repository is not archived. The README also advertises a bot that posts random rules periodically, which implies an ongoing publishing loop rather than a one-off dump. Upgrade cost is low in the ordinary sense, because there is nothing to upgrade in your own stack: the dependencies are devDependencies pinned with caret ranges, and the only reason to touch them is if you are running or forking the site itself. The real ongoing cost is editorial. Every entry is a claim about a live service, and the project does not document a process for retiring entries when a policy changes.

Editorial conclusion

Adopt this repository only if you want to read, mirror or contribute to a catalogue of bad password policies; it is a static site, not a dependency, so adding it to an application makes no sense. Before contributing, read CONTRIBUTING.md and check whether the rule you want to report already has an entry, and verify that a screenshot and a link to the offending page are acceptable evidence for the maintainer. If you need enforceable password policy guidance rather than examples of failures, look at NIST SP 800-63B or OWASP guidance instead. The one thing to verify first is that the site you are reporting still enforces the rule today, because a catalogue entry that describes a removed policy is worse than no entry.

Frequently asked questions

Official sources

1. duffn/dumb-password-rules on GitHub
2. Issues
3. License: MIT
4. Project website
5. README