Document ID: HYV-S2-PSW-001
Owner: CTO (Security Officer)
Approved by: Executive Leadership
Effective date: August 18, 2025
Next review: August 18, 2026 (or upon material change)
Applies to: All Hyvery workforce members (employees, contractors) and all systems, applications, and services that authenticate to or from Hyvery production and supporting environments.
Define controls for strong authentication and credential management for human and non‑human identities to reduce the risk of unauthorized access and credential compromise, aligned with SOC 2 (CC6, CC7) and informed by NIST SP 800‑63B and OWASP ASVS.
Hyvery SaaS platform (web, mobile, APIs), admin portals, and internal tools
Cloud infrastructure (DigitalOcean), Kubernetes clusters, Droplets, load balancers, firewalls, object storage, and MongoDB
CI/CD (GitLab), source code repositories, secrets stores, monitoring/telemetry (e.g., Sentry)
NIST SP 800‑63B (Digital Identity Guidelines)
OWASP ASVS 2.1.x (Authentication)
SOC 2 CC6 (Access Controls), CC7 (Change/Monitoring)
4.1 Authentication Baseline
SSO First: Production and corporate apps must use centralized SSO (SAML 2.0 / OIDC) where supported. Local accounts are disabled or restricted to break‑glass only.
MFA Required: MFA is mandatory for all workforce SSO accounts; phishing‑resistant factors (e.g., FIDO2/WebAuthn, passkeys) are preferred. Privileged roles (cloud, Kubernetes, database, CI/CD admins) require MFA at every elevation.
Session Security: Sessions time out after 15 minutes of inactivity (admin) and 30–60 minutes (standard users). Re‑authentication is required for sensitive actions.
Account Lockout / Brute‑Force: Lock account or introduce exponential back‑off after 10 failed attempts within 15 minutes; alert on anomalies.
4.2 Human Password Requirements (where passwords are used)
Length: Minimum 14 characters; allow passphrases up to 128 characters; allow spaces and all characters.
Quality: No composition rules beyond length; instead, enforce deny‑lists against common/compromised passwords and block user attributes (name/company).
Reuse/Rotation: Do not require periodic rotation absent suspicion or compromise (per NIST). Block reuse of last 10 passwords. Privileged local accounts rotate at least every 180 days.
Storage: Store passwords only as salted, memory‑hard hashes (preferred Argon2id; acceptable fallback bcryptwith cost ≥ 12). Unique 16‑byte+ salts per credential; optional global pepper stored in a restricted secrets service.
Reset/Recovery: Self‑service resets require second factor; recovery tokens expire in 15 minutes and are single‑use. No knowledge‑based questions. Admin‑initiated resets require ticket + manager approval.
4.3 Non‑Human Credentials (Service Accounts, API Keys, Tokens)
Least Privilege & Scoping: Create narrowly scoped service accounts per application/component; avoid using human credentials for automation.
Storage: Secrets are stored only in an approved secrets manager (e.g., cloud KMS/manager) or GitLab masked variables; never in source code, tickets, comments, or plaintext files.
Rotation: Rotate API keys and service secrets at least annually and upon personnel change, suspected compromise, or vendor advisories. High‑risk/privileged secrets rotate every 90 days.
TTL/Ephemeral Tokens: Prefer short‑lived tokens and signed JWTs with aud/iss validation; enforce expiry and audience checks.
Transport: Transmit secrets only over TLS 1.2+; never via email or chat without encryption.
Inventory: Maintain an up‑to‑date inventory of service accounts, owners, scopes, and rotation dates.
4.4 SSH Keys & OS‑Level Access
Key Algorithms: Use ed25519 (preferred) or ECDSA‑P256; RSA 3072+ only if required. Keys must be passphrase‑protected.
No Password SSH: Disable password‑based SSH on servers; enforce key‑based access via bastion or access broker.
Lifecycle: Register keys to individuals; rotate/expire at least annually and on role change/termination.
Logging: All privileged shell access is logged and correlated to a unique user.
4.5 Database & Application Credentials
Application DB Users: Separate accounts per service with minimal grants; disallow shared admin credentials.
Config Delivery: Inject credentials at runtime via environment variables or secrets volumes from the secrets manager; never commit to code or container images.
MongoDB Security: Enforce SCRAM auth, TLS, IP allow‑lists/NetworkPolicies, and role‑based privileges.
4.6 Monitoring, Detection & Response
Secrets Scanning: Enable GitLab secret detection in CI; block merges on detected secrets until remediated.
Log Hygiene: Never log passwords or full secrets; Sentry and app logs must scrub tokens, keys, and PII.
Anomaly Alerts: Alert on repeated failed logins, impossible travel, mass token revocations, and privilege escalations.
Compromise Response: Immediately revoke keys/tokens, invalidate sessions, rotate affected secrets, and initiate incident response.
4.7 Workforce Lifecycle & Access Reviews
Joiners: Provision least‑privilege roles; confirm MFA enrollment before granting production access.
Movers: Adjust access within 30 days of role change.
Leavers: Disable accounts and revoke tokens within 24 hours of separation; rotate shared secrets and transfer ownership.
Quarterly Reviews: System/data owners review all human and service accounts, roles, and privileged access at least quarterly.
4.8 Customer & End‑User Authentication (Product)
Support SSO (SAML/OIDC) for customers; encourage MFA.
Enforce product password controls consistent with §4.2 (length ≥ 12; deny‑list, lockout/back‑off, secure reset).
Provide account lockout, email/IdP verified resets, and audit logs to customers.
Security Officer (CTO): Owns this policy; approves exceptions; ensures audits and evidence.
Engineering Leads: Enforce controls in code, CI/CD, and infrastructure; ensure secure storage/rotation.
System/Data Owners: Maintain account inventories; perform quarterly access reviews; approve privileged access.
All Workforce: Protect credentials; use only approved managers; report suspected compromise immediately.
Exceptions require a documented justification, compensating controls, defined expiry, and Security Officer approval. High‑risk exceptions require executive approval and periodic review.
Violations may result in disciplinary action up to and including termination of employment or contract, loss of access, and potential legal action.
SOC 2 CC6.1/CC6.2: Logical access and authentication controls; least privilege; MFA.
SOC 2 CC7.2: Monitoring for security events; anomaly detection.
NIST 800‑63B: Password length, deny‑lists, MFA, secure recovery.
OWASP ASVS 2.1/2.2: Credential storage, lockout, and session controls.
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | 2025‑08‑18 | CTO | Initial release aligned to SOC 2, NIST 800‑63B, and OWASP ASVS. |