Inconsistent password validation between frontend and backend user creation

[dusanparipovic]

Description

Inconsistent password validation between frontend and backend when creating users. The UI enforces strict password rules (length, case, digit, special character), while the backend accepts any password. Scripts or direct API calls can create users with passwords that would be rejected by the UI, and the backend does not enforce the same policy.

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to Settings → Users (or the "Create user" screen).
2. Try to create a user with a password that has no special character (e.g. Password123).
3. See the frontend show a validation error (e.g. "Special characters required").
4. Call the create-user API directly (e.g. POST /v1/users) with the same username and password Password123.
5. Observe that the user is created successfully.

Actual Behavior

• Frontend: Rejects passwords that don't meet: min 8 / max 50 chars, at least one lowercase, one uppercase, one digit, and one special character.
• Backend: Accepts any non-empty password string. No length, character-type, or special-character checks; the password is only hashed and stored.
• Result: Automated scripts or API clients can create users with weak passwords (e.g. short, no special character) that the UI would never allow. Security policy is inconsistent and only enforced in the UI.

Expected Behavior

• The same password rules should apply whether the user is created via the UI or via the API.
• The backend should validate password strength (or delegate to a shared validation) and return a clear error (e.g. 400) when the password does not meet the policy, so that API consumers get the same guarantees as the UI.

Possible Solution

• Add server-side validation in the create-user flow (e.g. in UserCreateDTO or in LoginService.create_user) that mirrors the frontend rules (length 8–50, lowercase, uppercase, digit, special character). Reject the request with 400 and a clear message when validation fails.

Environment

• Production
• Staging
• Both (behavior is in code, not environment-specific)

Additional Information

Context

• We use a script for automatic creation of user accounts (e.g. Antares training). The script calls the create-user API and works as expected from the API's point of view.
• While testing, we noticed that the script can use passwords that the UI would reject (e.g. no special character). This led us to find that password validation exists only on the frontend, not on the backend.
• We consider this an inconsistency and a policy gap: the same security rules should apply regardless of whether the user is created via the UI or the API.

[TheoPascoli]

Hello @dusanparipovic, I'll take a look at this.