Skip to content

Hazard

DO NOT EDIT BELOW THIS LINE UNLESS YOU KNOW WHAT YOU ARE DOING

Hazard name

Weak secrets allowed in configuration

General utility label

[2]

Likelihood scoring

TBC

Severity scoring

TBC

Description

Settings class uses pydantic-settings but doesn't validate critical fields like JWT_SECRET minimum length or complexity, allowing production deployment with weak secrets.

Causes

  1. SecretStr type doesn't enforce length constraints or complexity
  2. No @validator function for JWT_SECRET, database passwords, or other secrets
  3. Weak secrets like "secret123" or "password" accepted without warning

Effect

Production deployment with weak JWT secret, database passwords, or other security-critical secrets.

Hazard

Attacker can brute force weak secrets and forge authentication tokens, access databases, or compromise system.

Hazard type

  • UnauthorizedAccess

Harm

Complete system compromise with unauthorized access to all patient records. Attacker could modify clinical data causing patient harm through falsified records leading to incorrect treatment decisions.

Existing controls

None identified during initial analysis.

Assignment

Clinical Safety Officer

Labelling

TBC (awaiting scoring)

Project

Clinical Risk Management

Hazard controls

Design controls (manufacturer)

  • Add Pydantic @validator for JWT_SECRET: validate minimum length 32 characters, entropy check using zxcvbn library (score must be >=4), no dictionary words, no common patterns. Raise ValidationError if validation fails. Application refuses to start with weak JWT_SECRET.
  • Implement entropy validation for all secrets: calculate Shannon entropy for JWT_SECRET, AUTH_DB_PASSWORD, EHRBASE_API_PASSWORD, VAPID_PRIVATE. Require minimum entropy 4.0 bits/character (high entropy indicates random generation). Reject secrets with entropy <3.5.
  • Add common secret blacklist: maintain list of 10,000 most common passwords from breach databases (password, admin, 123456, etc.). Check all secrets against blacklist. Reject if match found. Include common developer secrets (secret, changeme, test123).
  • Implement startup secret audit: on application start, log (to secure audit log, not stdout) whether secrets meet minimum security requirements. Flag weak secrets for immediate rotation. Send alert to security team if weak secrets detected in production.
  • Add secret generation helper script: provide scripts/generate_secure_secrets.py that generates cryptographically random secrets meeting all requirements. Script outputs secrets in .env file format. Documentation instructs deployments to use this script (not manually chosen secrets).

Testing controls (manufacturer)

  • Unit test: Create Settings with JWT_SECRET="short". Assert ValidationError raised with message "JWT_SECRET must be at least 32 characters".
  • Entropy test: Create Settings with JWT_SECRET="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" (32 'a' characters). Assert ValidationError raised with message "JWT_SECRET has insufficient entropy (score: X, required: 4)".
  • Blacklist test: Create Settings with JWT_SECRET="password123456789012345678901234" (32 chars but blacklisted). Assert ValidationError raised with message "JWT_SECRET contains common password pattern".
  • Startup test: Deploy application with weak JWT_SECRET in environment variables. Assert application fails to start with error message explaining secret requirements.
  • Generation script test: Run scripts/generate_secure_secrets.py. Parse output. Validate all generated secrets meet minimum length, entropy, and blacklist requirements.

Training controls (deployment)

  • Train operations team on secret generation: always use provided generation script, never manually create secrets, understand minimum entropy requirements, rotate secrets quarterly.
  • Document secret requirements in deployment guide: minimum 32 characters, high entropy (random generation), no dictionary words, use generation script. Include examples of acceptable vs unacceptable secrets.

Business process controls (deployment)

  • Secret strength policy: All production secrets must be cryptographically random, minimum 32 characters, generated by approved tool (scripts/generate_secure_secrets.py or password manager). Manual secret creation prohibited.
  • Pre-production security review: Before production deployment, security team audits all secrets using entropy validation tool. Deployment blocked if weak secrets detected. Secrets meeting requirements documented in deployment checklist.
  • Secret rotation schedule: JWT_SECRET, database passwords, VAPID keys rotated every 90 days. Rotation procedure uses generation script to create new secrets. Old secrets retired after grace period (allows both old and new secrets to coexist during rotation).
  • Incident response: If weak secret discovered in production (via security audit or breach), immediately rotate weak secret. Analyze logs for unauthorized access during period weak secret was active. Assess potential data breach impact.
  • DataBreach

Residual hazard risk assessment

TBC — awaiting initial controls implementation.

Hazard status

Draft from LLM

Code associated with hazard

  • backend/app/config.py