Password Policy Violation
URI: https://docs.ankatech.co/errors/password-policy-violation
HTTP Status: 400 Bad Request
When you see this
A password someone chose was refused by the platform's password policy. Nothing was stored: the previous password, if any, still applies, and a link or token used to reach the operation is still valid.
One policy applies wherever a person sets a password: choosing one during sign-in setup or enrolment, a password reset, a password change, and the administrator password of a newly provisioned tenant. The same value receives the same answer on every one of these paths, and the answer names the rule that refused it.
The policy follows NIST SP 800-63B-4:
| Rule | Requirement |
|---|---|
| Length | At least 15 and at most 128 characters |
| Characters | Any printable character, spaces included. Unicode values are compared after NFKC normalization |
| Blocklist | Not one of the common or compromised passwords bundled with the platform (more than 100,000 values), nor a product word such as ankasecure, compared after normalization and case folding. The list is checked offline; no password is sent anywhere |
| Context | Must not contain the local part of the person's e-mail address |
There is no composition rule (no required upper-case letter, digit or symbol) and no periodic expiry. A long passphrase such as harbour lantern quietly folding is accepted.
Reusing one of the account's recent passwords is a different refusal: Password Reused on a reset, and the invalid-password-change answer of a password change, which also covers a wrong current password.
Common Causes
- The password is shorter than 15 characters.
- The password is a common or previously breached value, or a variation the normalization folds onto one.
- The password contains the part of the e-mail address before the
@. - The password is longer than 128 characters.
Response Example
{
"type": "https://docs.ankatech.co/errors/password-policy-violation",
"title": "Password Policy Violation",
"status": 400,
"detail": "The password must be at least 15 characters long.",
"instance": "/api/v3/admin/platform/tenants/provision",
"timestamp": 1730000000,
"extensions": {
"requestId": "550e8400-e29b-41d4-a716-446655440000"
}
}
Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. Where the Admin API answers, the correlation identifier is extensions.requestId. On the Auth API paths (reset, change and sign-in setup) the body carries no correlation member; correlate through the X-Correlation-Id response header. See Error Index & Overview.
How to Resolve
- Choose a longer password: a passphrase of several unrelated words is the easiest way to reach 15 characters.
- Avoid common passwords and anything containing your e-mail address.
- Submit again. A reset or activation link is not consumed by a refused password.
For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.