From a931d5c63c5f59644130d02dedb5d15b450a0986 Mon Sep 17 00:00:00 2001 From: jsboige Date: Sat, 25 Jul 2026 21:10:16 +0200 Subject: [PATCH] docs(dnn): close the open prod-scope conditional in the machineKey runbook The runbook's threat model said the prod site "is the target IF it runs the exposed key" and left that untested. web1 classified the live prod web.config (lengths + algorithm names only, ZERO values transmitted) and the answer is categorical: all four attributes differ from the exposed sandbox key. exposed (4b0297ee): validationKey 128 hex / decryptionKey 64 hex / HMACSHA256 / AES prod web1: validationKey 40 chars / decryptionKey 48 chars / SHA1 / 3DES 40/48 + 3DES/SHA1 is the legacy ASP.NET shape (20 bytes for SHA1, 24 for 3DES); the sandbox used the modern shape. Prod cannot be running the exposed key. => Prod is OUT OF SCOPE of the compromise remediation. No emergency rotation, no session invalidation on argumentum.games. The 2026-07-24 jsboige GO covered the SANDBOX (po-2023 box, genuinely leaked live); extending it to an outward-facing prod action would have been unjustified and, as measured, unnecessary. Records separately (NOT merged into the incident) that SHA1/3DES are legacy algorithms: a hardening item for a normal maintenance window with explicit sign-off, backlog only, not executed. Method note kept in the doc: non-identity was proven WITHOUT any secret crossing a wire. Compare fingerprints, never values. Refs #131 #854 Co-Authored-By: Claude Opus 5 (1M context) --- docs/dnn/machinekey-rotation-scrub-runbook.md | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/dnn/machinekey-rotation-scrub-runbook.md b/docs/dnn/machinekey-rotation-scrub-runbook.md index fb93e400..036ab28e 100644 --- a/docs/dnn/machinekey-rotation-scrub-runbook.md +++ b/docs/dnn/machinekey-rotation-scrub-runbook.md @@ -20,6 +20,38 @@ **Why this matters** (threat model): a leaked `machineKey` lets an attacker forge DNN authentication cookies + tamper ViewState → **unauthenticated account impersonation / privilege escalation** on any DNN site using the same key. The prod site (`dnn.argumentum.myia.io`) is the target if it runs the exposed key. +### 0.1 That conditional is now RESOLVED — prod does **not** run the exposed key (2026-07-25) + +The clause above ("*…if it runs the exposed key*") was left open when this runbook was written. It is now closed on +evidence. `myia-web1` classified the **live prod** `web.config` (classification only — lengths + algorithm names, +**zero values transmitted**, per the secret-safe policy at the top of this file) and the result is categorical: + +| attribute | **exposed** key (sandbox, `4b0297ee`) | **prod web1** key (measured) | +|-----------|---------------------------------------|------------------------------| +| `validationKey` length | **128 hex chars** | **40 chars** | +| `decryptionKey` length | **64 hex chars** | **48 chars** | +| `validation` | **HMACSHA256** | **SHA1** | +| `decryption` | **AES** | **3DES** | + +**All four attributes differ.** These are not two instances sharing a key — they are keys of two different +generations. The 40/48 + 3DES/SHA1 shape is the **legacy ASP.NET machineKey format** (validationKey 40 hex = 20 +bytes for SHA1; decryptionKey 48 hex = 24 bytes for 3DES); the sandbox used the modern AES/HMACSHA256 shape. +Prod cannot be running the exposed key: it has neither its length nor its algorithms. + +**Consequence — prod is OUT OF SCOPE of this compromise remediation.** No emergency rotation, no maintenance +window, no session invalidation on `argumentum.games`. The jsboige GO of 2026-07-24 covered the **sandbox** +(the po-2023 box, whose key was genuinely leaked live); extending a sandbox-scoped GO to an outward-facing, +hard-to-reverse prod action would have been unjustified — and, as measured, factually unnecessary. + +> **Separate item, deliberately NOT merged into the above:** SHA1 and 3DES are legacy algorithms. That is a +> **hardening** observation, not an incident response. It belongs in a normal maintenance window with explicit +> jsboige sign-off — **not** in a compromise-remediation action, and not while he is unreachable. Tracked as +> backlog, not executed. + +**Method note worth keeping:** this was settled *without any secret crossing a wire*. Comparing lengths and +algorithm names was sufficient to prove non-identity. When you need to answer "is this the same key?", compare +fingerprints — never values. + --- ## A. Rotation (server-side — the ONLY real fix) — do FIRST