Skip to content

Sicherheit.en

Marcel edited this page Jul 9, 2026 · 1 revision

Deutsch | English

Security

Overview of HumanShield.APP's security mechanisms and recommendations for operation.

Authentication

  • Passwords: hashing with Argon2id (OWASP's primary recommendation).
  • Local login as the primary method; OIDC/SSO optional as a second method.
  • Two-factor authentication: TOTP (authenticator app) or email one-time code, with backup codes. Enforceable by admins (off / admins only / everyone).
  • Two-step login when 2FA is active: after the password, a short-lived, scoped pre-auth token that permits only the 2FA step — no regular API access.

Handling secrets

  • Runtime credentials (SMTP of the sending profiles and the fallback SMTP, LDAP bind password, OIDC client secret, TOTP secret): encrypted at rest via Fernet, key derived from SECRET_KEY.
  • Such secrets are never returned in plain text via the API — only a has_* flag.
  • Operator secrets (SECRET_KEY, DB password): exclusively via .env, never in code, never in the repo.
  • Backup codes are stored only as a hash; a used code is invalidated.

Data minimization in tracking

  • Only recorded is that a recipient opened/clicked/submitted a form (awareness signal) — including time and IP.
  • Submitted form data is not stored by default. "Data capture" and "capture passwords" are opt-in per landing page and should only be used after internal approval (data protection/works council).

Traceability

  • Audit log (Settings → Activity): sign-ins (success/failure/blocked) and system changes (users, settings, 2FA) with timestamp and IP.

Operation / hardening

  • Reverse proxy (Caddy) with TLS; can run behind an external TLS proxy.
  • Containers rootless and hardened, services on the internal Docker network.
  • Recommendations:
    • Set a strong, random SECRET_KEY (≥ 32 characters) and keep it secret.
    • Protect .env with chmod 600, never commit it.
    • Restrict access to the dashboard (VPN/network segmentation).
    • Regular database backups.
    • Assign roles sparingly (principle of least privilege).

Responsible use

Results serve to improve awareness, not to penalize individuals. Coordinate simulations and any data collection internally beforehand.

See also: Configuration · NIS2 & BSI

Clone this wiki locally