PCH-02-007-hibp-add-padding.patch.md

1.7 KB · raw

rendered · source

1# PCH-02-007 — Add `Add-Padding: true` to the HIBP k-anonymity range check23**Severity:** Informational4**Target file:** `src/background/vault.ts:230` (`checkBreach`)5**Report:** peach-code-review.md, Finding PCH-02-00767## Exact edit89```typescript10// BEFORE (vault.ts:230)11    const res = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`);1213// AFTER14    // PCH-02-007: HIBP pads the response to a fixed bucket size when asked,15    // so a network-position observer can't use response length to infer how16    // many suffixes a prefix returned. Padding lines are random suffixes with17    // count 0 — the suffix match below either misses them or parses 0, which18    // every consumer already treats as "not breached".19    const res = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`, {20      headers: { "Add-Padding": "true" },21    });22```2324## Parser compatibility (verified)2526Padded responses append fake `SUFFIX:0` lines. `checkBreach` parses27`text.split("\r\n").find((l) => l.startsWith(suffix))` then28`parseInt(line.split(":")[1], 10)`:2930- A padding line virtually never collides with the real 35-hex-char suffix;31  if one ever did, its count parses to `0`, and both `checkBreach`'s `match ?`32  expression and every caller (`breach > 0` / `count > 0` checks in33  vault.ts/messages.ts) already treat 0 as not-breached.34- No change needed to the response handling.3536## Tests3738`vault.hibp-padding.test.ts` (in this folder) — 3 tests: header present on the39range request (fetch spy), breach count still parsed from a padded response,40padding-line count-0 is not reported as a breach.41Destination: `src/background/vault.hibp-padding.test.ts`.4243## Save message (integration)4445`fix: PCH-02-007 add Add-Padding header to HIBP k-anonymity range check`