sebastiencarceles
commented
7 months ago @Queenze972 les règles pour les mots de passe sont les mêmes pour les users et pour les admins.
Situation actuelle
Les règles sont les suivantes :
- 8 caractères au moins
- 70 caractères au plus
- au moins un chiffre
- au moins une minuscule
- au moins une majuscule
- au moins un caractère spécial parmi la liste suivante :
#?!@$%^&*-
Le mot de passe n'est pas stocké tel quel en base. Il est d'abord chiffré et c'est ce chiffrement qui est stocké. Devise utilise Bcrypt pour le chiffrement, ce qui est considéré comme sûr et constitue un standard dans le monde des applications Ruby on Rails.
Par ailleurs, la base elle-même est chiffrée et n'est pas accessible par internet, seul le serveur y a accès :
Recommandations de la CNIL
Elle recommande de mettre en oeuvre une double authentification, OU BIEN de respecter les bonnes pratiques pour l'authentification par mot de passe simple.
Elle ne recommande pas de renouveler régulièrement les mots de passes.
Toutefois, la CNIL recommande de définir un niveau minimal générique de 80 bits d'entropie (à comprendre comme un score de sécurité du mot de passe). Avec nos règles actuelles, et d'après le calculateur, nous sommes à 53 bits d'entropie.
Pour atteindre 80, nous pouvons changer nos règles pour correspondre à l'exemple 1, qui est conforme aux préconisations :
Les changements pour nous seraient donc les suivants :
- passer à 12 caractères minimum
- élargir la liste de caractères spéciaux (pour atteindre 37 caractères spéciaux différents disponibles)
Une alternative (exemple 2 de la CNIL) serait de passer à 14 caractères minimum sans caractère spécial obligatoire :
Enfin, une autre possibilité proposée par la CNIL serait de rester avec une entropie minimum de 50, mais d'ajouter des mécanismes de restriction supplémentaires :
- Temporisation d'accès au compte après plusieurs échecs ;
- Nombre maximal de tentatives autorisées dans un délai donné ;
- "Captcha" ;
- Blocage du compte après 10 échecs assorti d'un mécanisme de déblocage choisi en fonction des risques d'usurpation d'identité et d'attaque ciblé par déni de service.
Nous avons déjà le mécanisme 4 en place grâce à Devise Lockable :
Handles blocking a user access after a certain number of attempts (10 tentatives dans notre cas). Lockable accepts two different strategies to unlock a user after it’s blocked: email and time. The former will send an email to the user when the lock happens, containing a link to unlock its account. The second will unlock the user automatically after some configured time (désactivé dans notre cas, c'est forcément par email).
Nous pourrions facilement mettre en oeuvre le mécanisme 2 grâce à du rate limiting.
Donc au bilan, notre situation actuelle (règles qui donnent une entropie de 53 et mécanisme de blocage) est conforme aux recommandations de la CNIL mais pourrait être améliorée, soit par :
- la modification des règles de mot de passe
- la mise en oeuvre d'un nouveau mécanisme de restriction (en l'occurrence le mécanisme 2 : nombre maximal de tentatives autorisées dans un délai donné)
Recommandations de l'ANSSI
L'ANSSI a publié un guide très exhaustif sur l'authentification. J'ai retenu que :
- la première recommandation est l'authentification multifacteur ou une authentification forte
- nos règles sur la complexité des mots passe sont dans l'état de l'art, sauf du point de vue de la longueur
Je n'ai pas étudié le guide en détail : j'ai l'impression que les recommandations convergent avec celles de la CNIL et j'arrive globalement aux mêmes conclusions. Est-ce que tu penses qu'il faut aller plus loin dans l'étude de ce guide et faire des propositions d'amélioration de l'application, au delà des mots de passe, en ce qui concerne l'authentification ?
Queenze972
Comme discuté par mail (échanges du 8/3) , nous aimerions avoir un audit/une analyse sur la robustesse des mots de passes sur l'application.
Merci.