Summary
Keycast should enforce a shared password policy whenever a new password is created, while continuing to allow existing users to log in with passwords they already set.
Environment
- Service: Keycast API
- Endpoints:
/api/headless/register, /api/auth/register, /api/auth/reset-password, authenticated change-password endpoint
Steps to Reproduce
- Register a new account with a weak password such as
1234 or password123.
- Or reset a password to a similarly weak value.
- Observe that some paths hash and accept the password without policy checks.
Actual Result
Registration and reset-password paths hash the submitted password directly. The authenticated change-password path enforces only a minimum length check. Existing password handling is inconsistent across endpoints.
Expected Result
New passwords are checked against one shared server-side policy before they are accepted. Existing password hashes remain valid for login so current users are not forced out or blocked by the new policy.
Regression?
No. This is a hardening and UX improvement.
Evidence
Relevant code inspected:
api/src/api/http/headless.rs: headless_register hashes req.password directly.api/src/api/http/auth.rs: register queues bcrypt for req.password directly.api/src/api/http/auth.rs: reset_password hashes req.new_password directly.api/src/api/http/auth.rs: change_password checks only new_password.len() < 8.
Acceptance Criteria
Summary
Keycast should enforce a shared password policy whenever a new password is created, while continuing to allow existing users to log in with passwords they already set.
Environment
/api/headless/register,/api/auth/register,/api/auth/reset-password, authenticated change-password endpointSteps to Reproduce
1234orpassword123.Actual Result
Registration and reset-password paths hash the submitted password directly. The authenticated change-password path enforces only a minimum length check. Existing password handling is inconsistent across endpoints.
Expected Result
New passwords are checked against one shared server-side policy before they are accepted. Existing password hashes remain valid for login so current users are not forced out or blocked by the new policy.
Regression?
No. This is a hardening and UX improvement.
Evidence
Relevant code inspected:
api/src/api/http/headless.rs:headless_registerhashesreq.passworddirectly.api/src/api/http/auth.rs:registerqueues bcrypt forreq.passworddirectly.api/src/api/http/auth.rs:reset_passwordhashesreq.new_passworddirectly.api/src/api/http/auth.rs:change_passwordchecks onlynew_password.len() < 8.Acceptance Criteria
/api/headless/registerrejects weak new passwords./api/auth/registerrejects weak new passwords./api/auth/reset-passwordrejects weak new passwords.1234,password, andpassword123are rejected for new submissions.