# Unified Login Security Notes

## Security boundary

The Unified User Portal is the only password authority. Each application receives an opaque cookie token, hashes it, loads the central session and current user/app/permission state, and fails closed when the central database or private configuration is unavailable.

Local application sessions contain only short-lived UI state and CSRF data. Local password verification was removed.

## Passwords and account recovery

- Minimum 14 characters
- Common/predictable phrases and account-detail combinations rejected
- Argon2id using configurable cPanel-safe costs when available
- Bcrypt cost 12 fallback when Argon2id is unavailable
- Five-password history
- Generated temporary passwords force change at next sign-in
- Password/security changes revoke central sessions through `auth_version`
- No email reset or SMTP dependency; an authorised portal administrator issues a temporary password

## Two-factor authentication

TOTP is mandatory for Administrator and Super Administrator accounts and cannot be disabled for those levels. Ten one-time recovery codes are generated. TOTP codes are consumed by time step to prevent replay, and recovery codes are atomically marked used. Replacing the authenticator or regenerating recovery codes requires recent password plus authenticator reauthentication.

Store recovery codes offline. Do not place them in application notes or ordinary email.

## Sessions

- 384-bit opaque tokens; only token hashes are stored in MySQL
- Secure, HttpOnly, SameSite cookies
- Host-only `__Host-` cookie preferred on one hostname
- Shared-domain `__Secure-` cookie only for trusted subdomains
- 30-minute idle and 12-hour absolute default expiry
- Optional user-agent binding enabled by default
- Server-side per-user revocation
- Session rotation after authentication and reauthentication
- Logout uses POST plus CSRF and revokes the shared session

## Login abuse controls

The portal records username/IP attempts, applies throttling and account locks, uses a dummy password hash to reduce account-enumeration timing differences, and returns generic login failures. High-impact reauthentication has its own failure handling and session revocation threshold.

## Authorization

A user needs both an enabled application grant and an allowed function. Explicit Deny overrides inheritance. Super Administrator protection is hard-coded for final-account safety. Delegated administrators cannot grant an app/function/level they do not hold or manage a target whose effective access exceeds theirs.

Application routes and submitted actions enforce permissions server-side. Local branch, manager, owner and record-state checks remain additional restrictions and cannot be bypassed by a central Allow.

## Web and file controls

- HTTPS required; HTTP redirects use trusted registered URLs, not the request Host
- HSTS available and enabled by default
- Restrictive Content Security Policy without `unsafe-inline`/`unsafe-eval`
- Frame, content-type, referrer, permissions, cache and opener/resource headers
- CSRF on state-changing requests
- Prepared SQL and escaped output
- MIME/size validation and random filenames for uploads
- Script execution disabled in upload directories
- Private data directories denied through `.htaccess`
- Central private config refused if located under the public document root

Apache/cPanel must honour `.htaccess`. On another server, reproduce the same denial and no-script-execution rules before deployment.

## Operational controls

- Keep `/home/CPANEL_USER/unified-auth-config.php` outside `public_html`, normally mode 0600.
- Use separate least-privilege database users for central login and Store Audit.
- Create and test a second Super Administrator.
- Review explicit permission overrides periodically.
- Disable departed users centrally and revoke unnecessary app grants.
- Keep PHP, cPanel and database software patched.
- Back up central config/database and linked application data as one recovery set.
- Remove ZIPs, migration reports and backup files from public web folders.
- Never use 777 as a routine permission fix.

## Residual deployment risks

Application security cannot compensate for a compromised cPanel account, a malicious sibling site sharing the same cookie parent domain, disabled `.htaccess`, publicly exposed database backups, incorrect TLS/proxy configuration or overly broad filesystem/database privileges. Validate these controls on the actual host before launch.