# NIVRA — Security Architecture 1.2 ## Identity and secrets Passwords use PHP `password_hash`/`password_verify`. Sensitive identity/contact fields use authenticated encryption through Sodium Secretbox when available or OpenSSL AES-256-GCM fallback. `app/config.local.php` and `storage/` are excluded from update packages and web access. Password recovery uses expiring single-use token hashes. A successful reset increments the session epoch and revokes trusted devices. Two-factor authentication supports TOTP authenticator apps and discreet e-mail codes. SMS/WhatsApp verification must remain unavailable until a real provider is configured. ## Session controls The app uses HttpOnly cookies, Secure cookies when HTTPS is active, SameSite=Lax, session regeneration, inactivity timeout, CSRF protection, trusted-device tokens and “sign out other devices”. Browsers may offer their own password manager; NIVRA does not write the user's raw password into local storage. ## Verification vault Civil name, document, selfie/video evidence and payment proofs are encrypted and stored outside the public web directory. Central Master access requires authorization; vault views require recent Master password reauthentication and are written to audit logs. Regional accounts do not have vault access. ## Adult-content boundary The safe shell may be navigated before verification. Adult media delivery, adult feed, messages, Radar and purchases require verified adult status. Master moderation also blocks publishing adult creator material owned by an unverified account. ## Media authorization Direct upload-directory access is denied. Media is served through an authenticated authorization route with `no-store` headers. Unauthorized Private posts render a neutral locked card and do not send the protected source file to the browser. Images receive a viewer-linked server watermark when GD is available, plus a visible client overlay. Videos use authenticated range streaming plus visible viewer watermarking. The application also blocks common save/drag/context-menu paths and uses a best-effort privacy shield. A normal website cannot guarantee prevention of operating-system screenshots, screen recording or photographing the display with another device. The product therefore treats watermarking, access control, auditing and takedown response as the real protection boundary rather than promising impossible screenshot prevention. ## Browser headers CSP, frame denial, MIME sniffing protection, same-origin referrer policy, COOP/CORP and Permissions-Policy are emitted. `display-capture=()` denies page-initiated display capture through the browser policy; camera and geolocation remain self-origin and permission-based. ## Updates Master updates require admin role, CSRF/session, Master password reauthentication, a valid ZIP package, safe-path allowlist, `update.json`, per-file SHA-256 checks, pre-update backup and rollback of replaced files on write failure. Additive database migrations execute separately and do not delete customer data. SHA-256 package hashes verify package consistency. A future licensed/franchise distribution milestone should add asymmetric vendor signing, immutable off-site audit storage, security monitoring/WAF and formal penetration testing.