fraqtal/agentic-dev
Template
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

fix(core-audit): keyed 128-bit pseudonyms + salted DSR certificate

Browse Source 
pseudonymize() used an unkeyed sha256 over 'salt:id' truncated to 64
bits, and the DSR deletion certificate hashed the raw subjectId with no
salt at all (audit finding A13). Both now use HMAC-SHA256 keyed by
AUDIT_PSEUDONYM_SALT, truncated to 128 bits. Rotation semantics are
documented on pseudonymize(): a key rotation changes future pseudonyms
only — stored rows keep old tokens and erasure still matches by real
actorId — and the certificate change likewise affects new certificates
only.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Danijel Martinek
2026-07-10 18:13:38 +02:00
parent 68a142fa6b
commit d95ae74aed
4 changed files with 68 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
packages/core-audit/src/pseudonymize.ts
View File

@@ -1,22 +1,34 @@
import { createHash } from "node:crypto";
import { createHmac } from "node:crypto";
/**
* Produces a stable, irreversible token for a GDPR-erased actorId.
*
* Format: `erased-<first-16-hex-chars-of-sha256(salt:actorId)>`
* Format: `erased-<first-32-hex-chars-of-HMAC-SHA256(key, actorId)>` —
* 128 bits of a KEYED digest (audit finding A13). The previous scheme was an
* unkeyed `sha256("salt:actorId")` truncated to 64 bits, which invited both
* brute-force reversal of small id spaces and birthday collisions.
*
* The salt is read from `AUDIT_PSEUDONYM_SALT` env at call time so that
* The HMAC key is read from `AUDIT_PSEUDONYM_SALT` at call time so that
* production binding can pre-validate the var at boot (see `bindAudit`)
* while tests can override it per-test via `process.env`.
*
* Fallback salt is intentionally weak and labelled so that any token
* Rotation expectations (documented, by design):
* - Rotating the key changes pseudonyms produced FROM THEN ON only. Audit
* rows already pseudonymized keep tokens derived from the previous key;
* nothing re-keys stored rows, so a subject's pre- and post-rotation
* tokens no longer correlate. That linkage break is acceptable — the
* token's only job is severing PII linkage, not long-term correlation.
* - Re-erasing a subject after rotation still works: erasure matches rows
* by the REAL actorId, not by a previous pseudonym.
* - Rotate by replacing the env value (e.g. `openssl rand -hex 32`); keep
* retired keys only if you have an explicit need to re-correlate old rows.
*
* Fallback key is intentionally weak and labelled so that any token
* produced with it is recognisable as a dev/test artefact.
*/
export function pseudonymize(actorId: string): string {
const salt =
const key =
process.env["AUDIT_PSEUDONYM_SALT"] ?? "dev-fallback-salt-replace-in-prod";
const hash = createHash("sha256")
.update(`${salt}:${actorId}`)
.digest("hex");
return `erased-${hash.slice(0, 16)}`;
const digest = createHmac("sha256", key).update(actorId).digest("hex");
return `erased-${digest.slice(0, 32)}`;
}