[PR #169] [CLOSED] fix: enforce strong password policy on admin user creation #209

New Issue

2026-06-06T22:09:42-04:00

yindo commented

2026-06-06 22:09:42 -04:00

📋 Pull Request Information

Original PR: https://github.com/vxcontrol/pentagi/pull/169
Author: @mason5052
Created: 3/2/2026
Status: ❌ Closed

Base: master ← Head: fix/user-password-validation

📝 Commits (1)

54da403 fix: enforce strong password policy on admin user creation

📊 Changes

1 file changed (+1 additions, -1 deletions)

View changed files

📝 backend/pkg/server/models/users.go (+1 -1)

📄 Description

Description of the Change

Problem

The password validation policy is inconsistent across user models:

Model	Context	Validation	Strength Check
`UserPassword`	Admin creates user	`max=100,required`	None
`Password`	User changes own password	`stpass,max=100,required`	Strong
`Login`	User login attempt	`min=4,max=100,required`	None (expected)

The UserPassword model accepts any password up to 100 characters with no minimum length or complexity requirement. An admin can create a user with a trivially weak password like "a" or "1234".

The Password model correctly uses the stpass (strong password) custom validator, which requires either:

16+ characters (any), OR
8+ characters with at least one uppercase, one lowercase, one digit, and one special character [!@#$&*]

Solution

Add the stpass validator to UserPassword.Password to enforce the same strength policy on admin user creation as on self-service password changes.

The Login model is intentionally left with min=4 since it only validates login attempt input, not password creation.

Type of Change

Bug fix (non-breaking change which fixes an issue)

Areas Affected

Core Services (Backend API)
Security (Authentication/Authorization)

Testing and Verification

Test Configuration

PentAGI Version: master @ e97bbe5
Docker Version: N/A (model validation change)
Host OS: Windows 11
LLM Provider: N/A

Test Steps

Reviewed init.go to confirm stpass validator is registered and uses strongPasswordValidatorString()
Verified strongPasswordValidatorString() logic: accepts 16+ chars OR 8+ with mixed case/digits/specials
Confirmed Password model already uses stpass successfully
Verified UserPassword is used in admin user creation path (services/users.go)

Test Results

After the fix, admin user creation rejects weak passwords with a validation error
Existing users with strong passwords are unaffected
The stpass validator is already battle-tested via the Password model

Security Considerations

This fix closes a password policy gap. Without it, an admin (or an attacker who compromises an admin account) can create users with trivially guessable passwords, bypassing the strong password policy enforced on self-service changes.

Performance Impact

None. The stpass validator uses pre-compiled regexes and runs in microseconds.

Deployment Notes

Breaking change for weak admin-created passwords only. After this fix, admin API calls to create users with passwords shorter than 8 characters (or 16 without complexity) will fail validation. Existing users are not affected unless their password is reset via the admin API.

Checklist

Code Quality

My code follows the project's coding standards
I have added/updated necessary documentation
All new and existing tests pass
I have run go fmt and go vet (for Go code)

Security

I have considered security implications
Changes maintain or improve the security model
Sensitive information has been properly handled

Compatibility

Changes are backward compatible
Dependencies are properly updated

Documentation

Documentation is clear and complete
Comments are added for non-obvious code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/vxcontrol/pentagi/pull/169 **Author:** [@mason5052](https://github.com/mason5052) **Created:** 3/2/2026 **Status:** ❌ Closed **Base:** `master` ← **Head:** `fix/user-password-validation` --- ### 📝 Commits (1) - [`54da403`](https://github.com/vxcontrol/pentagi/commit/54da4031321437afc85d96a1655288ea59a68be5) fix: enforce strong password policy on admin user creation ### 📊 Changes **1 file changed** (+1 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `backend/pkg/server/models/users.go` (+1 -1) </details> ### 📄 Description ### Description of the Change #### Problem The password validation policy is inconsistent across user models: | Model | Context | Validation | Strength Check | |-------|---------|-----------|---------------| | `UserPassword` | Admin creates user | `max=100,required` | None | | `Password` | User changes own password | `stpass,max=100,required` | Strong | | `Login` | User login attempt | `min=4,max=100,required` | None (expected) | The `UserPassword` model accepts any password up to 100 characters with no minimum length or complexity requirement. An admin can create a user with a trivially weak password like `"a"` or `"1234"`. The `Password` model correctly uses the `stpass` (strong password) custom validator, which requires either: - 16+ characters (any), OR - 8+ characters with at least one uppercase, one lowercase, one digit, and one special character `[!@#$&*]` #### Solution Add the `stpass` validator to `UserPassword.Password` to enforce the same strength policy on admin user creation as on self-service password changes. The `Login` model is intentionally left with `min=4` since it only validates login attempt input, not password creation. ### Type of Change - [x] Bug fix (non-breaking change which fixes an issue) ### Areas Affected - [x] Core Services (Backend API) - [x] Security (Authentication/Authorization) ### Testing and Verification #### Test Configuration ```yaml PentAGI Version: master @ e97bbe5 Docker Version: N/A (model validation change) Host OS: Windows 11 LLM Provider: N/A ``` #### Test Steps 1. Reviewed `init.go` to confirm `stpass` validator is registered and uses `strongPasswordValidatorString()` 2. Verified `strongPasswordValidatorString()` logic: accepts 16+ chars OR 8+ with mixed case/digits/specials 3. Confirmed `Password` model already uses `stpass` successfully 4. Verified `UserPassword` is used in admin user creation path (`services/users.go`) #### Test Results - After the fix, admin user creation rejects weak passwords with a validation error - Existing users with strong passwords are unaffected - The `stpass` validator is already battle-tested via the `Password` model ### Security Considerations This fix **closes a password policy gap**. Without it, an admin (or an attacker who compromises an admin account) can create users with trivially guessable passwords, bypassing the strong password policy enforced on self-service changes. ### Performance Impact None. The `stpass` validator uses pre-compiled regexes and runs in microseconds. ### Deployment Notes **Breaking change for weak admin-created passwords only.** After this fix, admin API calls to create users with passwords shorter than 8 characters (or 16 without complexity) will fail validation. Existing users are not affected unless their password is reset via the admin API. ### Checklist #### Code Quality - [x] My code follows the project's coding standards - [x] I have added/updated necessary documentation - [x] All new and existing tests pass - [x] I have run `go fmt` and `go vet` (for Go code) #### Security - [x] I have considered security implications - [x] Changes maintain or improve the security model - [x] Sensitive information has been properly handled #### Compatibility - [x] Changes are backward compatible - [x] Dependencies are properly updated #### Documentation - [x] Documentation is clear and complete - [x] Comments are added for non-obvious code --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

yindo added the pull-request label 2026-06-06 22:09:42 -04:00

yindo closed this issue

2026-06-06 22:09:42 -04:00

yindo referenced this issue

2026-06-06 22:09:50 -04:00

[PR #209] [CLOSED] fix: initialize buildMonitor in NewAssistantProvider and LoadAssistantProvider #237

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#209