Password field on both register and login accepts leading and trailing whitespace without trimming. Registering with " Constellation2026!" (leading space) succeeds, but a subsequent login with "Constellation2026!" (no space) fails with invalid credentials because the stored hash includes the space. Same behaviour with trailing space.
Realistic risk: user copy-pastes a password from a password manager, picks up an accidental leading or trailing space, and is silently locked out with no way to know why. Gmail and most modern auth flows trim leading/trailing whitespace on login to handle exactly this.
checkPasswordStrength in application/common/src/PasswordStrength.ts doesn't strip whitespace, and no .trim() is applied in AuthController.login or the various register endpoints either.
Related design question from the Slack discussion: whether we should ideally disallow spaces in passwords altogether, since they aren't meaningful characters in this context and only introduce fragility.
Password field on both register and login accepts leading and trailing whitespace without trimming. Registering with
" Constellation2026!"(leading space) succeeds, but a subsequent login with"Constellation2026!"(no space) fails with invalid credentials because the stored hash includes the space. Same behaviour with trailing space.Realistic risk: user copy-pastes a password from a password manager, picks up an accidental leading or trailing space, and is silently locked out with no way to know why. Gmail and most modern auth flows trim leading/trailing whitespace on login to handle exactly this.
checkPasswordStrengthinapplication/common/src/PasswordStrength.tsdoesn't strip whitespace, and no.trim()is applied inAuthController.loginor the various register endpoints either.Related design question from the Slack discussion: whether we should ideally disallow spaces in passwords altogether, since they aren't meaningful characters in this context and only introduce fragility.