Accept Diceware-style passphrases in the password strength gate

[deanrie]

Problem

isPasswordStrong requires 24+ characters and upper + lower + digit + symbol. That rejects a 7-word Diceware passphrase (correct horse battery staple whale pencil gravy, ~90 bits from the EFF long list) while accepting Aaaaaaaaaaaaaaaaaaaaaa1!. Composition rules optimise for the wrong thing — NIST SP 800-63B explicitly recommends length over composition — and passphrases are what people can actually remember for a 25-year secret.

Change

The existing rule is unchanged (and still what Generate produces). A second way to pass the gate is added:

• 24+ characters in total, and
• 6+ different words (case-insensitive) of 3+ letters each, separated by spaces, hyphens or underscores.

So aaa aaa aaa aaa aaa aaa aaa aaa (repeated word) and a b c d e f g h i j k l (1-letter words) still fail; cat dog owl fox bee ant fails on length.

Updated to match: the field hint (· 24+ chars with upper, lower, number, symbol — or a passphrase of 6+ words), the rejection message, and the README's strength-indicator bullet.

Verified

• Extracted the three functions from app.js and ran a 10-case table: all pass (Diceware with spaces/hyphens/underscores accepted; repeats, short words, 5 words, <24 chars, Tr0ub4dor&3 rejected; the old composition rule behaves identically to before).
• Served the rebuilt site/index.html, typed correct horse battery staple whale pencil → green border + "Password accepted" toast; CSP hashes re-pinned, no console errors.
• npm run test:crypto 91/91 (no crypto touched — this is UI-layer only).

site/index.html and SHA256SUMS.txt are the output of npm run build. Version string / CHANGELOG left to you.

Note: touches the built site/index.html, so it will conflict with #43 if both land — whichever merges second just needs npm run build re-run.

[deanrie]

Also available merged with every other review PR, in dependency order and verified together, as #57 — merge that or the individual PRs, not both.

[seQRets]

Thank you, Dean. I like the idea of accepting real passphrases, but this rule would also accept an ordinary sentence of common words, which is much weaker than its length suggests. That's a no-go for me, so I'm keeping the current password rule, and keeping the file as small and tight as possible.

Please keep the suggestions coming!