Sécurité des mots de passe

[Mikolajek]

Bonsoir,

Lors de la phase de création d'un compte, aucune indication n'est donnée quant à la politique de sécurité des mots de passe. Il serait toujours bénéfique pour l'utilisateur de lui indiquer clairement ce qu'on attend de lui. Il y a un nudge pour lui indiquer la qualité, c'est un premier pas ; mais il faudrait le coupler à un message claire sur le nombre de caractères si la taille est limitée, sur les caractères autorisés, etc. L'idée est de permettre à l'utilisateur d'imaginer son mot de passe en connaissance de cause, au lieu d'essayer... et de se faire refuser son mot de passe. L'utilisateur voit le mot de passe comme une contrainte, accepte de faire un effort d'imagination une fois, pas deux. La seconde fois, il adaptera simplement son premier essai en fonction du retour affiché, et utilisera quelque chose de beaucoup plus prédictif.

C'est loin d'être par hasard que je remonte ça, puisque curieusement, le formulaire de connexion ne gère pas les mots de passe de plus de 50 caractères : "Le mot de passe doit comporter au minimum 6 caractères" (et autant dire qu'ils y sont). Du coup, l'utilisateur, tout heureux de pouvoir créer son mot de passe de 256 caractères (si si, il y en a... moi, déjà), reste tout bêtement à la porte au moment de se connecter.

Autre souci : il est possible de mettre son identifiant en mot de passe. Identifiant : PN666-YULPA, mot de passe : PN666-YULPA. Il faut impérativement empêcher l'utilisateur de massacrer la sécurité de son compte avec ce genre de pratiques, et interdire également l'utilisation de son adresse mail comme mot de passe puisque j'imagine que c'est également possible.

Un autre point qui pourrait être intéressant : coupler le process d'inscription avec l'API de HaveIBeenPwned.com qui permet de confronter le mot de passe proposé à une gigantesque liste de mots de passe présents dans les plus gros "leaks". Si le mot de passe figure dans une des listes : merci d'en choisir un autre, sinon on laisse passer. A noter que la v2 permet de tester un mot de passe sans avoir à le transmettre intégralement (uniquement les premiers caractères du hash en SHA-1).

Merci !

[Aurelien P.]

Bonjour, 

je vais voir pour ajouter des informations en effet alors  

On utilise une classe JS issue de Dropbox. Il n'y a pas de caractères obligatoires ou minimum, c'est l'ensemble qui est calculé.

Pas cool en effet que l'utilisateur puisse mettre son login en mdp, on va arranger cela également. Et pas cool pour les 50 caractères en effet 😢 

Pour le dernier point, HaveIBeenPwned, pas fan du concept perso

[Mikolajek]

Merci du retour.

Alors visiblement il y a un minimum de 9 caractères, puisque je n'arrive pas à avoir le champ en vert avec 8 caractères, 4 types sur 4. Par contre, 9 caractères c'est OK, même avec uniquement un seul type de caractères. Il faudrait donc annoncer qu'il n'y a pas de restriction sur les types (ça plaît à l'utilisateur) mais qu'il y a un minimum de caractères, en plus d'une fonction de détection des mots de passe trop simples ou trop courants.

Juste pour information, on est en dessous des recommandations minimum de la CNIL (https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=DCFF485B7666F100CC93BF17B5D6BB27.tpdila17v_1?cidTexte=JORFTEXT000033928007&dateTexte=&oldAction=rechJO&categorieLien=id&idJO=JORFCONT000033926715). Par contre, si la classe JS permet de faire du calcul d'entropie et de déterminer un seuil minimum en bits, on peut adapter.

Qu'est-ce qui vous déplaît dans le concept de HIBP ? C'est une vraie question, la réponse m'intéresse. J'y vois surtout la possibilité d'alerter l'utilisateur sur le danger de la réutilisation des mots de passe : Mme Michu s'est inscrite il y a quelques années sur LinkedIn avec son mot de passe qu'elle réutilise partout, son mot de passe est donc dans la nature depuis la fuite de données chez LinkedIn. Si elle veut s'inscrire ici et réutiliser le même mot de passe, c'est l'occasion de lui dire "attention, le mot de passe figure dans un leak, il faut en changer". Le danger, pour elle, c'est que celui qui tombe sur son mail et son mot de passe LinkedIn vienne tenter cette combinaison ici... et il arrivera à se connecter. Pour celui qui pense créer un mot de passe très original, c'est l'occasion de lui dire que non, manifestement il n'est pas si original que ça, et surtout il est déjà compromis, donc la sécurité de son compte Yulpa serait également compromise, ainsi que celle de tous les autres sites où il utilise ce mot de passe.

Chacun utilise l'outil à sa façon : certains sites l'utilisent en refusant catégoriquement tout mot de passe qui serait référencé chez HIBP, d'autres avertissement simplement l'utilisateur qui décide seul s'il maintient son choix de mot de passe ou non, d'autres encore imposent la double authentification pour ceux qui maintiennent un mot de passe référencé chez HIBP.

[Aurelien P.]

Merci pour les premiers points / tests, j'améliorerais cela   

On ne peut pas appliquer les recommandations de la CNIL, bien qu'on fasse en sorte de sensibiliser nos utilisateurs, nous avons aussi des personnes qui sont plutôt "novice". Donc obliger par exemple 12 caractères c'est malheureusement trop pour beaucoup de gens.

Si les utilisateurs veulent renforcer la sécurité nous avons mis en place toute la partie firewall avec double authentification, restriction des IP...

Le code utilisé pour le JS est : https://github.com/dropbox/zxcvbn 

Pour HIBP, je suis partagé, votre explication tient clairement la route mais on ne peut pas (nous) palier toutes les faiblesses des utilisateurs, pourquoi pas en "avertissement" mais clairement pas en mettant la moindre restriction.