I Picked 150,000 Password Hash Iterations and the Platform Said No

The signup worked in every check I had run, and the first real one failed. The password hash was set to 150,000 PBKDF2 iterations, and Cloudflare Workers caps that at 100,000.

What I was building

We had a client portal prototype where any password worked. The login screen even said so. It ran on a Worker with a Durable Object holding the accounts, and the job was to turn it into a real product: real password creation, real rejection of wrong passwords, and service requests that persist instead of a fake checkout.

The design was ordinary. PBKDF2 with SHA-256 through WebCrypto, a random salt per user, the salt and iteration count stored next to the hash, and a constant-time comparison on login. A new account hashes and stores the password and starts a session. An existing account with the wrong password gets a 401 and no session.

For the iteration count I picked 150,000. It sat comfortably above the 100,000 figure I remembered from older guidance, and I did not look up what Workers allows.

The wrong turn: choosing the number from memory

Nothing I had could have caught it. The iteration count is a runtime argument to one function. A build does not execute that function, and neither does a type check, so both were clean. The first call that reaches the hashing step with real parameters is a real signup on the deployed Worker, and that call returned a server error.

The symptom was narrow. The check endpoint answered correctly and the client side behaved. Only the step that creates the hash failed, and only in the deployed runtime. That pointed straight at the one line that depended on the platform.

The platform rejects PBKDF2 above 100,000 iterations. It does not clamp the value. It throws.

The fix, and the verification that mattered

The fix was one number, 100,000, with a comment beside it saying why it cannot be higher. Then I ran the whole path against the live service instead of trusting the change:

1. A new email gets the create-your-password screen, and creating the account lands on onboarding.
2. Signing back in with the wrong password shows the inline error, with no session and no dashboard.
3. The right password goes straight to the dashboard.
4. A service request is recorded and shows as requested after a reload.

All four passed. That night the change was committed with the real login, the recorded requests, and every prototype badge removed.

What I would tell my earlier self

A platform limit is a fact about the platform, and I had stored it in my head from a different context. The check took a minute: look up the limit for the exact call before choosing the parameter.

The bigger habit is what I count as a test. A signup that never reaches the hashing step proves the form works. The proof that the login is real is the one that creates a real account on the real runtime, then tries the wrong password, then the right one.

The number is 100,000 now, and the comment next to it is the first thing anyone changing it will read.

dxdev LESSON · paste into your AI coding agent
LESSON: A Platform Limit Only Shows Up on the Live Path
SOURCE: dxdev.com/blog/2026-07-09_cf-pbkdf2-workers-limit
WHAT HAPPENED: A client portal prototype accepted any password. I turned it into real password auth on Cloudflare Workers using PBKDF2 through WebCrypto, with a per-user random salt and a constant-time compare. I chose 150,000 iterations from memory of general guidance and did not check what the platform allows. Workers caps PBKDF2 at 100,000 iterations and throws above it. The failure only appeared when a real signup reached the hashing call in the deployed runtime, so it was invisible to anything that did not execute that call. Setting the count to 100,000 fixed it, and I re-ran signup, wrong-password rejection, onboarding and request persistence against the live service.
THE RULE: Runtime limits are not visible to builds, type checks or dry runs. When you introduce a call with a tunable parameter on a hosted platform, look up that platform's limit for it, and make the first live test exercise that exact call end to end.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any crypto or hashing parameter (iterations, key size, memory cost) chosen without checking the target runtime's documented limits.
  2. Any release that treated a clean build or dry run as evidence about runtime behaviour.
  3. Any auth flow whose live test stops before the step that actually hashes or verifies a password.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.