docs(tests): E5 validated by code inspection, distinguish it from E9

Web storage and process memory are different artefacts; the dump scan says nothing about the former. Also flags the removeItem('cryptoKey') cleanup as deliberate, not dead code.
This commit is contained in:
r-zakarya
2026-08-07 11:46:18 +01:00
parent c1e5d14eac
commit 485dd3631e
+4 -1
View File
@@ -368,10 +368,13 @@ ou le déchiffrement.
- **Monter un WebDAV authentifié pour le test** : `python -m wsgidav.server.server_cli -c <config.json>` avec `simple_dc.user_mapping` et **`accept_basic: true`, `accept_digest: false`** — notre client n'envoie que du Basic. Le partage ne doit plus être marqué `(anonymous)` au démarrage. Un premier 401 suivi d'un 200 authentifié dans le journal est **normal** : WinHTTP n'envoie les identifiants qu'après le défi.
- **Piège de saisie** : les champs identifiant / mot de passe n'enregistrent que sur `change` (perte du focus). Taper puis cliquer aussitôt sur *Test connection* peut lire la préférence avant son écriture — les deux passent par des navigations `cmd://`, qui se coalescent. Faire Tab avant de cliquer.
### E5 · la clé du coffre n'est plus en clair dans le web storage
### E5 · la clé du coffre n'est plus en clair dans le web storage ✅
- **ACTION** : coffre déverrouillé → console WebView2 :
`sessionStorage.getItem('cryptoKey')`.
- **ATTENDU** : `null`. (Avant : une string base64 de 44 car = la clé AES.)
- **Vérifié par le code, 2026-08-03** — la console est indisponible en prod (DevTools désactivé), mais le résultat est structurel : plus aucun `persistCryptoKey` / `restoreCryptoKey` (seul subsiste le commentaire qui documente leur retrait), et `sessionStorage` ne porte que `username`, `salt`, `kdfIterations`, `hashAlgo`, `authToken`, `csrfToken`, `argon2Params`. Ni sel ni itérations ne sont des secrets — `/login/challenge` les publie.
- **`sessionStorage.removeItem('cryptoKey')` est volontaire** ([js/app.js](js/app.js)) : il efface le blob laissé par une **ancienne** version de l'app. Ne pas le supprimer en croyant à du code mort.
- **Ne pas confondre avec E9** : celui-ci porte sur le web storage (fichiers sur disque), E9 sur la mémoire du processus. Une clé peut être absente de l'un et présente dans l'autre.
- **Bonus** : dump mémoire du renderer → `this_is_password` peut persister
(strings V8, non corrigeable) ; c'est la **clé** qu'on a retirée du storage.