Development #34601
CNIL, complexité du code de suivi
0%
Description
Actuellement 8 caractères parmi BCDFGHJKLMNPQRSTVWXZ (20 caractères), donc log(20^8)/log(2) = 34.. bits d'entropie.
Si on se réfère à la page1 de la CNIL concernant les mots de passe, en considérant que le code de suivi est un mot de passe servant aussi d'identifiant, on devrait avoir 12 caractères avec majuscule, minuscule, chiffres et caractères spéciaux, mais comme ce ne sont pas les utilisateurs qui choisissent je pense qu'on peut enlever les caractères spéciaux en ayant une assez bonne entropie, si on ajoute du throttling avec temps d'attente exponentiel (on ne pourra se baser que sur l'IP, on a pas d'autre identifiant pour fixer le compteur de throttling) on peut descendre à 8, soit log((2*26+10)**8)/log(2) = 47 bits d'entropie.
À voir si on préfère allonger le code, ajouter de nouveaux caractères ou jouer sur la force du throttling, par exemple limiter à 10 échec consécutifs par heure et par /24 (et en IPv6 je ne sais pas trop, il me semble qu'on ne sert pas nos sites en IPv6 pour l'instant...).
1 https://www.cnil.fr/fr/authentification-par-mot-de-passe-les-mesures-de-securite-elementaires
Demandes liées
Historique
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
- Lié à Project management #34599: Suivi du respect des contraintes CNIL ajouté
Mis à jour par Frédéric Péters il y a presque 5 ans
- Lié à Development #34459: possibilité de code de suivi plus long ajouté
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
- Sujet changé de CNIL, longueur du code de suiv à CNIL, complexité du code de suivi
Je renomme en complexité du code de suivi puisqu'il y a déjà un ticket sur la longueur elle même.
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
Thomas signale que la crainte de la CNIL concerne des attaques force-brute distribuées, dans ce cas une possibilité et d'ajouter une preuve de travail (PoW) pour limiter la possibilité de distribuer l'attaque, ou en tout cas rendre son coup prohibitif (chaque essaie par IP coûtant plus cher en calcul, voir impossible si les bots sont "idiots", i.e. n'utilisent pas un navigateur).
Prévoir un jeton CSRF aussi sur la vue pour interdire les attaques JS distribuées.
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
- bloquer les ips à partir d'une blocklist DNS (noeud de sortie Tor, IP connues pour spam/botnet, etc..)
- poser un cookie signé longue durée dès qu'une interaction réussie (création d'une demande, login, soumission correcte d'un code suivi), ce cookie désactive toutes les protections pour ce client
Mis à jour par Paul Marillonnet il y a presque 5 ans
Benjamin Dauvergne a écrit :
ajouter une preuve de travail (PoW)
Qu'est-ce que tu verrais "dans la vraie vie", i.e. une solution qui ne pénalise pas l'usager honnête du système ?
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
En période d'attaque il faut pénaliser tout le monde, sauf ceux qu'on connaît déjà (d'où l'idée du cookie), dès qu'on fait un essaie raté on invalide le cookie, donc même un attaquant aurait récolté un ou des cookies à l'avance ne pourra faire qu'un essai par cookie avant de se faire bloquer.
Mis à jour par Mikaël Ates il y a plus de 2 ans
- Lié à Development #58837: Sécurité du code de suivi/d'accès ajouté
Mis à jour par Thomas Noël il y a presque 2 ans
- Statut changé de Nouveau à Fermé
Avantageusement remplacé par #59027