KC-1423: fix validation for passwords and passphrase in record creation and updation

[sshrushanth-ks]

Summary

Password/passphrase complexity policy checks were being applied even to manually typed passwords, so a weak password entered by hand on record-add, record-update, nsf-record-add, nsf-record-update, and the legacy add/edit v3 commands could get blocked by the enterprise complexity policy. Enforcement is now scoped to passwords produced by $GEN/--generate — manual entries are saved as-is, while generated passwords still get validated and warned on as before.

Changes

• Core validation refactor (record_edit.py, recordv3.py, enforcement.py): Added validate_generated_password(password, algorithm) to validate at generation site with correct allow_passphrase_fallback flag. Removed instance flags. Fixed v3 --generate blocker by renaming enforce_generated_password_policy() parameter from password to manual_password. Added allow_passphrase_fallback parameter to enforcement methods so generated random passwords preserve their error messages.

• nested_share_folder/record_commands.py: Added warning checks after field processing in add/update execute methods. Warnings log and block execution unless --force is used. Removed duplicate validation helpers.

• Tests (test_nested_share_folder.py, test_passphrase_enforcement.py, test_passphrase_generator.py): Updated 4 NSF tests to expect manual weak passwords to be allowed. Added tests confirming manual passwords skip warnings while generated passwords surface errors. Updated keyPair test to verify validate_generated_password() is called. Fixed patch path in test_add_record.

[craiglurey]

I don’t agree with this. The whole point of enterprise enforcements is to ensure that users can’t type or generate a weak password. The functionality of Commander needs to be the same as the user on the vault. I'd like to understand where this requirement came from.

[amangalampalli-ks]

I don’t agree with this. The whole point of enterprise enforcements is to ensure that users can’t type or generate a weak password. The functionality of Commander needs to be the same as the user on the vault. I'd like to understand where this requirement came from.

We identified a bug in Commander: when both password and passphrase policies were applied, it incorrectly validated constraints across fields - for example, displaying a passphrase policy error while a user was entering a password.
After reviewing the Vault’s behavior, we found that it enforces these policies only in the generator, not during manual field entry. We therefore planned to update Commander to align with the Vault’s current behavior.