[GH-ISSUE #1219] [Bug]: On a default Docker install, MFA_ENCRYPTION_KEY is not set #887

New issue

Open

opened 2026-05-07 00:14:43 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-07 00:14:43 +02:00

Owner

Originally created by @maziggy on GitHub (May 6, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1219

Originally assigned to: @netscout2001 on GitHub.

Component

Bambuddy

Bug Description

On a default Docker install, MFA_ENCRYPTION_KEY is not set, so:

OIDC client_secret values are stored as plaintext in the database
TOTP secrets (2FA enrollments) are stored as plaintext in the database

The encryption module (backend/app/core/encryption.py) emits a single WARNING log line at startup pointing this out, but the warning is not surfaced anywhere a user is likely to see it. Setup wizards, the Settings UI, and the docker-compose template do not mention MFA_ENCRYPTION_KEY at all, so an admin who wires up OIDC and asks users to enroll TOTP can reasonably believe those secrets are protected at rest when in fact they are not.

This is a meaningful security degradation for any install that uses either feature. Users actively using OIDC SSO are the most likely to be affected because the OIDC client_secret is directly disclosable from the SQLite database without any decryption step.

Expected Behavior

In a current Docker deployment (v0.2.4b3, support bundle attached on a separate ticket), the warning fires on every startup:

WARNING [backend.app.core.encryption] MFA_ENCRYPTION_KEY is not set — TOTP secrets and OIDC client_secrets are stored in plaintext.

The same install has active POST /api/v1/auth/oidc/exchange traffic in the access log, confirming OIDC is in use against an unencrypted client_secret column.

Steps to Reproduce

Printer Model

None

Bambuddy Version

0.2.3.2 and up

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

No response

Screenshots

No response

Additional Context

Migration considerations

Legacy plaintext rows must keep working when a key is later configured — the current mfa_decrypt path already handles this (no fernet: prefix → returned as-is). So auto-bootstrap is non-breaking for existing installs: the key gets generated, new writes are encrypted, old reads still work, and the UI can prompt for re-enrollment to migrate.

Key rotation is a separate (harder) problem and is out of scope here — the current code raises on rotation, which is fine until someone asks for it.

Severity / impact

Affects: any install using OIDC SSO or TOTP 2FA, which is the entire population of users actually relying on the auth features
Likelihood: 100% on default Docker installs unless the operator has read the warning in the logs
Impact: at-rest secret exposure; database backup or restore-from-bad-source leaks usable credentials directly

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode
My printer has Developer Mode enabled

Originally created by @maziggy on GitHub (May 6, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1219 Originally assigned to: @netscout2001 on GitHub. ### Component Bambuddy ### Bug Description On a default Docker install, MFA_ENCRYPTION_KEY is not set, so: - OIDC client_secret values are stored as plaintext in the database - TOTP secrets (2FA enrollments) are stored as plaintext in the database The encryption module (backend/app/core/encryption.py) emits a single WARNING log line at startup pointing this out, but the warning is not surfaced anywhere a user is likely to see it. Setup wizards, the Settings UI, and the docker-compose template do not mention MFA_ENCRYPTION_KEY at all, so an admin who wires up OIDC and asks users to enroll TOTP can reasonably believe those secrets are protected at rest when in fact they are not. This is a meaningful security degradation for any install that uses either feature. Users actively using OIDC SSO are the most likely to be affected because the OIDC client_secret is directly disclosable from the SQLite database without any decryption step. ### Expected Behavior In a current Docker deployment (v0.2.4b3, support bundle attached on a separate ticket), the warning fires on every startup: WARNING [backend.app.core.encryption] MFA_ENCRYPTION_KEY is not set — TOTP secrets and OIDC client_secrets are stored in plaintext. The same install has active POST /api/v1/auth/oidc/exchange traffic in the access log, confirming OIDC is in use against an unencrypted client_secret column. ### Steps to Reproduce . ### Printer Model None ### Bambuddy Version 0.2.3.2 and up ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Docker ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package _No response_ ### Screenshots _No response_ ### Additional Context Migration considerations Legacy plaintext rows must keep working when a key is later configured — the current mfa_decrypt path already handles this (no fernet: prefix → returned as-is). So auto-bootstrap is non-breaking for existing installs: the key gets generated, new writes are encrypted, old reads still work, and the UI can prompt for re-enrollment to migrate. Key rotation is a separate (harder) problem and is out of scope here — the current code raises on rotation, which is fine until someone asks for it. Severity / impact - Affects: any install using OIDC SSO or TOTP 2FA, which is the entire population of users actually relying on the auth features - Likelihood: 100% on default Docker installs unless the operator has read the warning in the logs - Impact: at-rest secret exposure; database backup or restore-from-bad-source leaks usable credentials directly ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled