Développement #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
Related issues
History
Updated by Benjamin Dauvergne almost 6 years ago
- Related to Gestion de projet #34599: Suivi du respect des contraintes CNIL added
Updated by Frédéric Péters almost 6 years ago
- Related to Développement #34459: possibilité de code de suivi plus long added
Updated by Benjamin Dauvergne almost 6 years ago
- Subject changed from CNIL, longueur du code de suiv to 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.
Updated by Benjamin Dauvergne almost 6 years ago
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.
Updated by Benjamin Dauvergne almost 6 years ago
- 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
Updated by Paul Marillonnet (retour le 22/04) almost 6 years ago
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 ?
Updated by Benjamin Dauvergne almost 6 years ago
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.
Updated by Mikaël Ates over 3 years ago
- Related to Développement #58837: Sécurité du code de suivi/d'accès added
Updated by Thomas Noël almost 3 years ago
- Status changed from Nouveau to Fermé
Avantageusement remplacé par #59027