🔐 Architecture de sécurité

Transparence assumée. Cette page documente nos défenses et leurs limites. Pas de sécurité par l'obscurité : une red team mérite de savoir ce qu'elle attaque. Tout le code est sous licence AGPL-3.0. Pour le cadre du test, voir les règles d'engagement ; pour les démonstrations, l'Attack Simulator.

1. Authentification — SelfRecover sans email

Aucun email, aucun n° de téléphone. À l'inscription : mot de récupération choisi → password (16 car.) + passphrase diceware EFF générés côté serveur.
Stockage : Argon2id(password), Argon2id(passphrase), Argon2id(clé_dérivée) — m=64 Mio, t=4, p=2 (profil OWASP). Aucun secret en clair.
Dérivation liée au nom d'hôte, lu par le navigateur : HMAC-SHA256(clé = mot mémorisé, message = nom d'hôte ‖ "|v2" ‖ sel du compte) → un mot hameçonné sur une autre adresse ne produit pas la bonne clé.
Rate-limit progressif (5 échecs / 15 min) + limite d'inscription par IP (anti-énumération, anti-spam).

2. Chiffrement des données — deux modèles selon la sensibilité

a) Blind-key serveur (profil : bio, localisation, lien) — XChaCha20-Poly1305, clé dérivée d'un secret serveur stocké hors base et hors webroot. Un dump SQL ne révèle que des blobs.

b) Bout-en-bout côté client (mémo perso) — chiffré dans le navigateur (WebCrypto). Argon2id (64 Mio, t=3, p=1 — profil partagé SelfDataGuard / SelfRecover, défini dans Primitives et tenu égal par un test de conformité) → HKDF par étiquette → une vault_key aléatoire chiffre le mémo, wrappée dans deux enveloppes (mot de passe + passphrase de secours). Le serveur ne détient aucune clé.

✅ Ce que ça protège

Blind-key : vol de disque, dump SQL, injection
E2E : même un accès admin ou root sur le serveur → le mémo reste illisible

⛔ Ce que ça ne protège pas (assumé)

Blind-key : un admin / un RCE qui lit la clé peut déchiffrer le profil & les DM
E2E : un serveur compromis persistant servant un JS piégé captant le mot de passe au déverrouillage (faille du « code servi »)

3. Une clé par usage — SelfRecover, le mémo, SelfDataGuard

Chaque usage dérive sa propre clé, par sa propre dérivation. L'accès passe par SelfRecover : ton navigateur calcule une empreinte HMAC-SHA256 de ton mot, liée au nom du site et salée par compte ; le serveur n'en garde qu'un Argon2id. Le mémo tire deux clés filles, séparées par étiquette HKDF : data-enc depuis ton mot de passe, data-recover depuis ta passphrase de secours.
Règle d'or : jamais la même clé pour l'authentification et le chiffrement (le serveur voit l'auth, il ne doit jamais pouvoir déchiffrer).
Récupération : si la passphrase de secours de ton mémo est aussi celle de SelfRecover, un seul secret rend l'accès et le mémo — par deux dérivations distinctes, sans clé commune. La force du secours = entropie de l'entrée (passphrase diceware), pas la taille du hash.

4. Durcissement applicatif

CSRF : jeton HMAC lié à la session, vérifié sur chaque action d'écriture (en-tête X-CSRF-Token).
En-têtes : Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, HSTS.
Sessions : jeton aléatoire 192 bits, cookie HttpOnly/SameSite=Lax, TTL 24 h + purge.
Anti-énumération : messages d'erreur non discriminants, limite par IP.

5. Modération — SelfModerate anti-manipulation

Réputation par membre (départ 20/30), vote ±1 sur les messages et les membres, motif exigé au vote négatif.
Anti-Sybil : un compte de moins de 2 minutes sans contribution ne peut pas voter.
Meute : des votants liés entre eux (messages privés dans les deux sens) qui frappent la même cible → votes annulés, réputation restaurée. Salve de votes sans lien → signalée à un arbitre, rien n'est annulé.
Anti-farming : votes répétés d'un membre vers un même autre neutralisés. Sanctions graduées : perte du vote, puis ban de 2 minutes → 10 minutes → 30 minutes — le dernier palier se reconduit, jamais définitif, et chaque ban s'écrit au journal de modération.

6. Modèle de menace — honnête

✅ Neutralisé

Exfiltration de la base (dump, disque volé) — blobs
Bruteforce de mot de passe (rate-limit)
Manipulation de la modération (Sybil, pack-voting)
CSRF, clickjacking, vol de session passif
Vol du mémo, même avec un accès root (E2E au repos)

⚠️ Limites connues

Profil & DM lisibles par qui obtient la clé serveur (.blindkey), par exemple via un RCE — pas par le panneau admin
Serveur compromis persistant → altération du code servi (« code servi »)
Métadonnées non chiffrées (qui parle à qui, quand)

7. Feuille de route

E2E étendu aux messages privés et au profil · superviseur d'intégrité hors machine : l'altération du code servi et les requêtes hors périmètre sont déjà détectées, mais depuis la machine surveillée — un accès root persistant peut donc faire taire le témoin ; restent à construire le témoin extérieur et le confinement automatique réversible · quorum distribué (Shamir) pour les clés critiques.