storytime/docs/specs/jalon-5-code-parental/02-stockage-securise.md

5.2 — Stockage sécurisé & vérification

Objectif

Implémenter ParentalCodeRepository : stocker le code de façon sûre (haché, jamais en clair) et vérifier une saisie.

Périmètre & hors-périmètre

• Inclus : hachage du code, stockage via flutter_secure_storage, vérification.
• Exclus : écrans (5.1/5.3).

Dépendances

5.1 (interface + ParentalCode).

Conception

• Data (features/parental/data/) :
  • SecureParentalCodeRepository implements ParentalCodeRepository.
  • Stocke un hachage du code (+ sel) dans flutter_secure_storage — jamais la valeur en clair.
    • Pour 4 chiffres, l'espace est petit (10 000 combinaisons) : le hachage protège contre la lecture directe du stockage, sans prétendre à une résistance forte au brute-force hors-ligne. C'est cohérent avec le modèle de menace (garde-fou enfant, cf. CLAUDE.md §1). Documenter ce choix.
  • isConfigured() = présence de la clé ; verify(code) = comparaison des hachages (comparaison à temps constant si simple à faire).
• DI : parentalCodeRepositoryProvider.

Plan TDD

1. Red : secure_parental_code_repository_test.dart — avec un flutter_secure_storage mocké :
   • setCode écrit une valeur différente du code en clair (hachée).
   • verify renvoie true pour le bon code, false sinon.
   • isConfigured reflète la présence de la clé.
2. Green : implémenter hachage + repository.
3. Refactor.

Definition of Done

• Tests verts ; aucune écriture du code en clair (vérifié par le test).
• tool/check.sh passe ; étape 5.2 cochée dans ROADMAP.md ; choix du modèle de menace consigné.

Risques / notes

• flutter_secure_storage s'appuie sur le Keystore Android : tester aussi le cas « valeur absente » au premier lancement.
• Ne pas réinventer de crypto : utiliser une fonction de hachage standard de crypto.