Password Policy

1. General

This Password Policy sets the requirements for creating, storing, managing and changing passwords across the platform: user accounts, administrative areas, API keys and service accounts.

The policy relies on the following standards:

• NIST SP 800-63B Rev. 4 — Digital Identity Guidelines (applied in full to the maximum level: administrators)
• ISO/IEC 27001:2022, Annex A 5.17 — Authentication information
• OWASP ASVS v4.0.3, section 2.1 — Password security
• CIS Controls v8, Control 5 — Account Management
• GDPR — protection of personal data

2. Password Requirements

2.1 Length and composition

2.2 Blocklist and history

When a password is set, the system checks it against:

• a list of the most commonly used passwords;
• passwords found in known data breaches (Have I Been Pwned, k-anonymity — the password never leaves the platform in clear text);
• context-specific values, such as the account e-mail;
• the user's last 5 passwords (history).

3. Password Lifecycle

3.1 Password change

Periodic forced password rotation is not applied: per NIST SP 800-63B it leads to predictable passwords and gives no security benefit. A password never expires because of its age.

A password change is required when:

• a compromise is confirmed or suspected (leak, breach database match, signs of unauthorized access);
• the password is weaker than the level now required for the account (for example, after a role upgrade).

In case of a suspected leak an administrator or the platform marks the account; on the next request the user is redirected to the password change page and cannot continue until the password is changed. The mark is removed by the change itself.

3.2 Self-service password reset

• The user chooses "Forgot password" on the sign-in page.
• The system sends a one-time link to the registered, verified e-mail.
• The new password must pass every check of section 2.

3.3 Failed sign-ins and sessions

4. Multi-Factor Authentication (MFA)

MFA is available to every user and is mandatory for administrators. Time-based one-time codes (TOTP) from an authenticator app are supported.

5. Storage and Transmission

• Passwords are never stored in plain text; they are stored only as salted bcrypt hashes (cost 12 or higher).
• All connections use TLS; passwords are never passed in URL parameters.
• MD5, SHA-1 and SHA-256 are not used for password hashing.

6. Single Sign-On (SSO)

Corporate tenants can sign in through an external identity provider (SAML 2.0, OAuth 2.0 / OpenID Connect). Multi-factor authentication for such sign-ins is enforced by the identity provider.

7. Audit and Monitoring

Authentication events are logged: successful and failed sign-ins, password changes and resets, MFA enrollment, account lockouts. Repeated failures lead to the temporary lockout described in section 3.3 and are available to the security team.

8. User Guidance

• Use a passphrase: several random words and a number.
• Use a password manager.
• Enable MFA wherever it is available.
• Never share a password and never reuse it on another service.

9. Compliance and Review

The policy is reviewed:

• once a year as a regular cycle;
• after a security incident that affects the platform;
• when new regulatory requirements appear.