Development #63830
interdire les mots de passe communs
0%
Description
Ça fait partie des recommandations actuelles du NIST,
When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:
- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
- Context-specific words, such as the name of the service, the username, and derivatives thereof.
If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.
Il y a https://docs.djangoproject.com/en/2.2/topics/auth/passwords/#module-django.contrib.auth.password_validation on pourrait utiliser UserAttributeSimilarityValidator et CommonPasswordValidator.
Fichiers
Révisions associées
Historique
Mis à jour par Corentin Séchet il y a presque 2 ans
On utilise déjà du code maison dans DefaultPasswordChecker, qui est appelé en JS pour mettre à jour les formulaires de mot de passe. C'est trivial de passer par là pour utiliser https://github.com/dwolfhub/zxcvbn-python cité dans #63831. zxcvbn implémente à la fois ce que fait UserAttributeSimilarityValidator et CommonPasswordValidator (il faudra potentiellement ajouter des dictionnaires de mot de passes communs en français).
La question est au niveau du feedback : actuellement on a des checks qui correspondent à une condition précise (minuscules / majuscules / longueur du mot de passe) qui passent en vert quand le mot de passe proposé les respecte dans l'interface. Dans le cas de zxcvbn, on a au final une force de mot de passe entre 0 et 4, mais les raisons qui mènent au calcul sont multiples et ne peuvent pas être connues à l'avance (répétition de lettres, mot de passe dans le dictionnaire). Je suggère de présenter ça comme un check 'Mot de passe suffisament sécurisé (raison pour laquelle le mot de passe n'a pas le score requis)' dans un premier temps, puis d'ajouter un feedback spécifique de force du mot de passe / suggestions d'amélioration dans un deuxième temps via #63831.
Mis à jour par Frédéric Péters il y a presque 2 ans
- Fichier Screenshot 2022-05-18 at 12-03-02 Services en ligne - Authentic.png Screenshot 2022-05-18 at 12-03-02 Services en ligne - Authentic.png ajouté
Ça me semble ok, dans l'idée ça serait donc un contrôle supplémentaire, qui pourrait être actif en combinaison des autres, un peu comme la maquette attachée, voire à terme laissé seul (la préco nist), j'ai bien compris ?
Mis à jour par Corentin Séchet il y a presque 2 ans
- Fichier maquette-1.png maquette-1.png ajouté
- Fichier maquette-2.png maquette-2.png ajouté
Oui, je me dis même que dans un premier temps on pourrait éluder les raisons pour lesquelles le score est trop faible, juste ajouter un test sur la force du mot de passe :
Puis dans #63831 ajouter un feedback pour la force du mot de passe en particulier :
Pour les autres tests (classes de caractères et longueur), je ne sais pas si à terme on peut les enlever, c'est redondant au moins en partie avec le test de force du mot de passe, mais ça permet une validation plus fine et ça peut être intéressant d'avoir toutes les conditions affichées.
Mis à jour par Corentin Séchet il y a presque 2 ans
- Fichier 0001-misc-validate-password-strength-63830.patch 0001-misc-validate-password-strength-63830.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Pour gérer ce que fait UserAttributeSimilarityValidator (qui est supporté par zxcvbn via le paramètre "user_inputs"), c'est un peu plus compliqué : soit on récupère les attributs sur l'utilisateur identifié (dans le cas d'un changement de mot de passe), soit il faut que le JS envoie les attributs (dans le cas où on crée un nouvel utilisateur par exemple). Je pense que ça vaut un ticket à par entière si on veut faire ça.
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
- Statut changé de Solution proposée à Solution validée
A-t-on des sources de mots de passe commun pour zxcvbn et pourrait-on donner une mini doc pour les installer (ici ou ailleurs) ?
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
Corentin Séchet a écrit :
Pour gérer ce que fait UserAttributeSimilarityValidator (qui est supporté par zxcvbn via le paramètre "user_inputs"), c'est un peu plus compliqué : soit on récupère les attributs sur l'utilisateur identifié (dans le cas d'un changement de mot de passe), soit il faut que le JS envoie les attributs (dans le cas où on crée un nouvel utilisateur par exemple). Je pense que ça vaut un ticket à par entière si on veut faire ça.
Oui tu peux ouvrir un ticket pour étendre l'API en ce sens (à voir si c'est un booléen "check_against_current_user_attribute" ou un dico "user_attributes" dans ValidatePasswordSerializer, ou les deux).
Mis à jour par Corentin Séchet il y a presque 2 ans
Benjamin Dauvergne a écrit :
A-t-on des sources de mots de passe commun pour zxcvbn et pourrait-on donner une mini doc pour les installer (ici ou ailleurs) ?
Le package python intègre uniquement des dictionnaires anglais. Il est possible de charger des dictionnaires personnalisés. J'ai trouvé ça : https://github.com/tarraschk/richelieu, je ne sais pas s'il y a des dictionnaires plus reconnus. Est-ce qu'on veut copier ce genre de dico dans le dépot authentic, ou est-ce qu'on prévoit de les charger depuis quelque part et laisser soin de les fournir lors de l'installation ?
Oui tu peux ouvrir un ticket pour étendre l'API en ce sens (à voir si c'est un booléen "check_against_current_user_attribute" ou un dico "user_attributes" dans ValidatePasswordSerializer, ou les deux).
Je fais ça.
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
Corentin Séchet a écrit :
Benjamin Dauvergne a écrit :
A-t-on des sources de mots de passe commun pour zxcvbn et pourrait-on donner une mini doc pour les installer (ici ou ailleurs) ?
Le package python intègre uniquement des dictionnaires anglais. Il est possible de charger des dictionnaires personnalisés. J'ai trouvé ça : https://github.com/tarraschk/richelieu, je ne sais pas s'il y a des dictionnaires plus reconnus. Est-ce qu'on veut copier ce genre de dico dans le dépot authentic, ou est-ce qu'on prévoit de les charger depuis quelque part et laisser soin de les fournir lors de l'installation ?
Je ne sais pas comment est packagé python3-zxcvbn mais si on peut faire un paquet Debian companion qui installe ces fichiers au bon endroit, faisons cela, on pourra le déployer ensuite via puppet, sinon dans authentic, c'est du CC BY ça passe je pense.
Mis à jour par Corentin Séchet il y a plus d'un an
- Statut changé de Solution validée à Résolu (à déployer)
commit 8e15762cd5801e13075c3caa851bc4e69833ed11 Author: Corentin Séchet <csechet@entrouvert.com> Date: Wed May 18 11:29:27 2022 +0200 misc: validate password strength (#63830)
Mis à jour par Transition automatique il y a plus d'un an
- Statut changé de Résolu (à déployer) à Solution déployée
misc: validate password strength (#63830)