Là où il a raison c’est que la CNIL recommande les caractères spéciaux. En ce moment je dev un projet où on doit scrupuleusement respecter leurs recommandations et je sais d'avance que ça va faire c**** les utilisateurs pour rien (mieux vaudrait forcer une longueur plus importante) pourtant je n’y peux rien.
C'est triste de devoir suivre les recommendations de la CNIL pour de la sécu… C'est pas vraiment un organisme spécialisé dans la sécurité informatique. L'ANSSI serait plus en mesure d'être écoutéee. Bon courage ;-)
Les recommandations de l'ANSSI sont quand même grosso-modo les mêmes que la CNIL.
« Choisissez des mots de passe composés si possible de 12 caractères de type différent (majuscules, minuscules, chiffres, caractères spéciaux) n’ayant aucun lien avec vous (nom, date de naissance…) et ne figurant pas dans le dictionnaire. »
J’allais poster ce lien ! Malheureusement oui… sinon j’aurai un bon argument pour faire différemment. J’ai bien tenté xkcd mais ce n’est malheureusement pas un organisme officiel
https://www.xkcd.com/936/
La taille n'est pas le seul facteur en prendre en compre pour mesurer la solidité d'un mot de passe. Par exemple, en ligne, le nombre de tentative possible par minute est beaucoup plus faible qu'en offline car il existe des mécanismes pour éviter les attaques par force brute.
Les calculs qu'il donne sont sur la génération des hash de mots de passe. Donc quand on connaît le sujet et qu'on sait de quoi on parle, on comprend très vite que c'est plutôt en lien avec le cas d'un leak de BDD contenant des empreintes de mots de passe.
Donc avant d'accuser les gens de ne pas savoir de quoi ils parlent, tourne sept fois la langue dans ta bouche, et ensuite prend ton clavier… ou pas.
Même si on parlait d'un cas d'un leak de base de données, son argumentaire ne tient pas. L'exemple de calcul qu'il fait se base sur des hash réalisé avec l'algorithme SHA256 ?
Qui utilise l'algorithme SHA256 pour stocker des mots de passe et est développeur en 2019 ?
On utilisera plutôt argon2 ou bcrypt pour réaliser cette tâche. Ces algorithmes sont beaucoup plus long à calculer que les algorithmes de type SHA* De plus, les bonnes pratiques du côté des sauvegardes en base de données et d'ajouter un sel et de jouer n fois l'algorithme de hash dans le but de ralentir encore plus les attaques par forcebrute à froid.
L'idée n'est pas mauvaise en soi, plus la taille des mots de passe est long et sans contraintes de caractère, mieux c'est. Par contre, je trouve que les arguments pour encourager cette démarche ne sont pas vrais.
Une fois que la bdd a fuité, c'est gameover. Il faut faire changer les mots de passe de tous les utilisateurs, peu importe la longueur.
Là où il a raison c’est que la CNIL recommande les caractères spéciaux. En ce moment je dev un projet où on doit scrupuleusement respecter leurs recommandations et je sais d'avance que ça va faire c**** les utilisateurs pour rien (mieux vaudrait forcer une longueur plus importante) pourtant je n’y peux rien.
C'est triste de devoir suivre les recommendations de la CNIL pour de la sécu… C'est pas vraiment un organisme spécialisé dans la sécurité informatique. L'ANSSI serait plus en mesure d'être écoutéee. Bon courage ;-)
Les recommandations de l'ANSSI sont quand même grosso-modo les mêmes que la CNIL.
« Choisissez des mots de passe composés si possible de 12 caractères de type différent (majuscules, minuscules, chiffres, caractères spéciaux) n’ayant aucun lien avec vous (nom, date de naissance…) et ne figurant pas dans le dictionnaire. »
Source (2017) : https://www.ssi.gouv.fr/uploads/2017/01/guide_cpme_bonnes_pratiques.pdf
J’allais poster ce lien ! Malheureusement oui… sinon j’aurai un bon argument pour faire différemment. J’ai bien tenté xkcd mais ce n’est malheureusement pas un organisme officiel https://www.xkcd.com/936/
La taille n'est pas le seul facteur en prendre en compre pour mesurer la solidité d'un mot de passe. Par exemple, en ligne, le nombre de tentative possible par minute est beaucoup plus faible qu'en offline car il existe des mécanismes pour éviter les attaques par force brute.
Pour information, la CNIL a publié un guide sur les règles concernant la longueur des mots de passe et l'on voit bien que des mots de passe de 8 caractères sont jugés acceptables par la CNIL pour les sites internet si d'autres critères sont présents. https://www.cnil.fr/fr/authentification-par-mot-de-passe-les-mesures-de-securite-elementaires
Faire les calculs, c'est bien, savoir de quoi on parle, c'est mieux. Encore plus quand on veut faire la leçon aux développeurs.
Les calculs qu'il donne sont sur la génération des hash de mots de passe. Donc quand on connaît le sujet et qu'on sait de quoi on parle, on comprend très vite que c'est plutôt en lien avec le cas d'un leak de BDD contenant des empreintes de mots de passe.
Donc avant d'accuser les gens de ne pas savoir de quoi ils parlent, tourne sept fois la langue dans ta bouche, et ensuite prend ton clavier… ou pas.
Même si on parlait d'un cas d'un leak de base de données, son argumentaire ne tient pas. L'exemple de calcul qu'il fait se base sur des hash réalisé avec l'algorithme SHA256 ?
Qui utilise l'algorithme SHA256 pour stocker des mots de passe et est développeur en 2019 ?
On utilisera plutôt argon2 ou bcrypt pour réaliser cette tâche. Ces algorithmes sont beaucoup plus long à calculer que les algorithmes de type SHA* De plus, les bonnes pratiques du côté des sauvegardes en base de données et d'ajouter un sel et de jouer n fois l'algorithme de hash dans le but de ralentir encore plus les attaques par forcebrute à froid.
L'idée n'est pas mauvaise en soi, plus la taille des mots de passe est long et sans contraintes de caractère, mieux c'est. Par contre, je trouve que les arguments pour encourager cette démarche ne sont pas vrais.
Une fois que la bdd a fuité, c'est gameover. Il faut faire changer les mots de passe de tous les utilisateurs, peu importe la longueur.