Website Administrator Password Policy

1. Purpose

This policy establishes minimum security requirements for administrator passwords on the Black X Marketing Inc. website, aligned with current NIST SP 800-63B (Revision 4) digital identity guidelines. Since the site has no public user registration and only employee-level administrators hold accounts, controls are focused on hardening privileged access rather than managing large user populations.

2. Account Eligibility

• Administrator accounts may only be provisioned for current Black X Marketing Inc. employees; there is no self-service or public registration path on the website.
• Each administrator account must be tied to a unique, named individual. Shared or generic admin logins are prohibited.
• Accounts must be deactivated immediately upon an employee’s termination, role change removing admin duties, or extended leave.
• Requests for new administrator accounts must be approved by a designated site owner (e.g., agency principal or IT lead) before provisioning.

3. Password Requirements

Because administrator accounts are privileged and high-value targets, length and uniqueness are prioritized over legacy complexity rules, consistent with NIST’s 2026 guidance:

• Minimum length: 15 characters (NIST’s recommended floor for single-factor privileged authentication); passphrases are encouraged.
• Maximum length: At least 64 characters must be accepted so administrators can use full passphrases or password-manager-generated strings.
• Character support: All printable ASCII and Unicode characters, including spaces, must be accepted.
• No forced composition rules: Do not require specific mixes of uppercase, lowercase, numbers, or symbols. These rules push users toward predictable patterns and are no longer recommended.
• No password hints. The system must never store or display hints, as they leak clues to attackers.
• Breach/blocklist screening: Every new or updated password must be checked against known breached-password and common-password lists at creation time, and rejected if it matches.
• Uniqueness: Administrators must not reuse passwords from other personal or business systems.

4. Password Storage — Administrators Cannot View Passwords

Because no one, including other administrators, may ever view a stored password, the website must never store passwords in a reversible or plaintext form:

• Passwords must be stored only as salted, irreversible cryptographic hashes, never in plaintext, and never encrypted in a way that permits decryption back to the original value.
• Recommended hashing algorithm: Argon2id, with bcrypt as an acceptable fallback if Argon2id is unavailable in the site’s stack.
  • Argon2id minimum configuration: ~19 MiB memory, iteration count of 2, parallelism of 1.
  • If using bcrypt: work factor of 10 or higher, respecting the 72-byte input limit.
• A unique, randomly generated salt (minimum 16 bytes) must be applied per password; salts do not need to be secret and may be stored alongside the hash.
• The plaintext password entered by an administrator must be discarded from memory immediately after hashing/verification. It is never logged, cached, or persisted anywhere.
• Because the system architecture makes decryption impossible by design (only a one-way hash exists), no administrator, including super-admins or developers, has any technical means to view another administrator’s actual password. This satisfies the “administrators can update but not view passwords” requirement at the data-layer level, not just the UI level.
• Use timing-safe comparison functions during login verification to prevent timing attacks.

5. Password Changes and Resets

• Self-service updates only: An administrator may only set or change their own password by authenticating first (current password or a secure reset link) and entering a new password. The interface must never display, pre-fill, or reveal the existing password value.
• No periodic forced rotation. Consistent with NIST guidance, do not require administrators to change passwords on a fixed schedule (e.g., every 90 days); this practice is deprecated and tends to weaken security by encouraging predictable pattern reuse.
• Mandatory change triggers: A password change must be required immediately if any of the following occur:
  • Evidence or suspicion of account compromise or a data breach.
  • The password is found on a breach/blocklist screen.
  • An administrator suspects their credentials were shared, observed, or intercepted.
• Reset workflow: Password resets must go through a secure, verified channel (e.g., a time-limited reset link sent to the administrator’s verified company email), never through a support staff member manually setting or reading a password. Reset requests should be rate-limited and logged.
• Password history: The new password must be meaningfully different from the administrator’s previous password to prevent trivial recycling (e.g., “Password1” to “Password2”).

6. Authentication Hardening

• Multi-Factor Authentication (MFA) is required for all administrator accounts. Given administrators control the entire website, MFA (authenticator app or, where supported, a phishing-resistant method such as a hardware key/passkey) should be mandatory, not optional.
• Account lockout: Lock an account after no fewer than 10 consecutive failed login attempts, with a cooldown or manual unlock process, balancing security against accidental lockout.
• Rate limiting: All login and password-reset endpoints must be rate-limited to slow brute-force and credential-stuffing attempts.
• Session security: Administrator sessions should time out after a period of inactivity and use secure, HTTP-only session cookies.
• Copy-paste support: Login and password fields must allow paste and autofill so password managers function correctly. Never block pasting into a password field.

7. Logging and Auditing

• Log all administrator authentication events (successful logins, failed attempts, password changes, resets, and lockouts) with timestamps, without ever logging the password value itself.
• Review access logs periodically for unusual login patterns (e.g., logins from unfamiliar locations or at odd hours).
• Maintain an audit trail of administrator account creation and deactivation tied to employment status.

8. Roles and Responsibilities

Role	Responsibility
Employee/Administrator	Choose a unique, sufficiently long passphrase; enable MFA; never share credentials; report suspected compromise immediately
Site Owner / IT Lead	Approve and provision new admin accounts; deactivate accounts on termination or role change; review access logs
Developer/Engineering	Implement salted Argon2id (or bcrypt) hashing, breach screening, MFA, rate limiting, and ensure no code path ever exposes stored password values

9. Policy Review

This policy should be reviewed at least annually, or sooner if NIST guidance changes, a security incident occurs, or the website’s authentication architecture is updated.