3.5 — Identification & Authentication

Identification & Authentication (IA) Policy

Establishes requirements for identifying and authenticating users, processes, and devices before granting access to OCSI systems — covering 11 controls per NIST SP 800-171 Rev 2.

Family: 3.5 — IAControls: 11Owner: Kit E. Floyd, Jr.Last Review: April 3, 2026
SELF-ASSESSMENT

Control statuses below reflect an internal self-assessment prepared with AI assistance. Statuses marked "Implemented" may be organizational claims without verifiable evidence. See POA&M for known gaps.

Policy Statement

OCSI shall identify and authenticate users, processes, and devices as a prerequisite to allowing access to organizational systems containing CUI. Authentication mechanisms shall employ cryptographic protections and meet FIPS compliance standards.

Control Implementation
ControlRequirementImplementationStatus
3.5.1Identify system users, processes acting on behalf of users, and devicesSingle hardcoded admin account identified by email address. Gap: No individual user accounts, no user directory, no device identification. Partial
3.5.2Authenticate (or verify) the identities of users, processes, or devices as a prerequisite to allowing accessAuthentication via email + password verified against SHA-256 hash using Web Crypto API. CRITICAL: Plaintext password ('OCSIAdmin2026!') is visible in source code (line 773). Client-side only — bypassable via DevTools. Critical Gap
3.5.3Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accountsNOT IMPLEMENTED. Zero MFA code exists. Only single-factor (password) authentication. This is a CMMC Level 2 mandatory requirement. Not Implemented
3.5.4Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accountsSessionStorage-based tokens — not cryptographically generated. No server-side token validation. Gap: sessionStorage.setItem('ocsi_admin_auth','true') grants instant access. Not Implemented
3.5.5Prevent reuse of identifiers for a defined periodSingle hardcoded credential — only one account exists. No identifier management system. Not Implemented
3.5.6Disable identifiers after a defined period of inactivitySessions terminated after 30 minutes of inactivity (client-side). Gap: No permanent account disablement for inactive users — only one account exists. Partial
3.5.7Enforce a minimum password complexity and change of characters when new passwords are createdNOT IMPLEMENTED. No password complexity validation code exists. No minimum length check, no complexity regex. Single hardcoded password. Not Implemented
3.5.8Prohibit password reuse for a specified number of generationsNOT IMPLEMENTED. No password change functionality exists. Single hardcoded credential. Not Implemented
3.5.9Allow temporary password use for system logons with an immediate change to a permanent passwordNOT IMPLEMENTED. No password change mechanism. No temporary password flow. Not Implemented
3.5.10Store and transmit only cryptographically-protected passwordsCRITICAL FAILURE. The plaintext password 'OCSIAdmin2026!' is in the JavaScript source code (line 773), visible to anyone who views page source. SHA-256 (not bcrypt/Argon2) is computed at runtime from this plaintext. Critical Gap
3.5.11Obscure feedback of authentication informationPassword input uses type="password" with masked display. Error messages show generic "Invalid credentials." This control is properly implemented. Implemented
Password Requirements Summary
  • Minimum 12 characters
  • At least one uppercase letter, one lowercase letter, one number, and one special character
  • Cannot reuse last 12 passwords
  • Maximum password age: 90 days (organizational policy)
  • Account lockout: 5 failed attempts → 15-minute lockout
  • Stored as SHA-256 hash only — never in plaintext
Cryptographic Standard: All password hashing uses the Web Crypto API crypto.subtle.digest('SHA-256', ...), which is a FIPS 140-2 compatible implementation built into modern browsers.