The checkPasswordStrength function currently only receives the
password itself. A user can register with something like
Firstnamelastname2026!- passes length, upper/lower/number, and the
common-words blocklist, but is trivially guessable because it's
derived from their own identity.
NIST SP 800-63B Section 3.1.1.2 suggests screening against
"context-specific words, such as the name of the service, the
username, and derivatives thereof":
https://pages.nist.gov/800-63-4/sp800-63b.html
Slack discussion with @ignatiusm raised a few implementation
considerations worth capturing here: form-field-fill order (user may
type password before their name), names not yet in DB during signup
(only email is available server-side via the invite record), and
names being available in the reset flow via the token relation.
The
checkPasswordStrengthfunction currently only receives thepassword itself. A user can register with something like
Firstnamelastname2026!- passes length, upper/lower/number, and thecommon-words blocklist, but is trivially guessable because it's
derived from their own identity.
NIST SP 800-63B Section 3.1.1.2 suggests screening against
"context-specific words, such as the name of the service, the
username, and derivatives thereof":
https://pages.nist.gov/800-63-4/sp800-63b.html
Slack discussion with @ignatiusm raised a few implementation
considerations worth capturing here: form-field-fill order (user may
type password before their name), names not yet in DB during signup
(only email is available server-side via the invite record), and
names being available in the reset flow via the token relation.