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/
C'est toujours le même problème : tant que les outils numériques restent des aides à la décision, pas de problème. Sauf que ça fini trop souvent en décision (pseudo-)automatisée, où la personne ne prend plus le recul nécessaire pour remettre en question l'avis du système…
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. »
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 ;-)
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.
Autant bon, la reconnaissance faciale c'est pas ouf, tout ça, et suspecter / accuser juste parce que la machine a dit « c'est lui », c'est limite, autant si l'image est nette et qu'on le reconnaît clairement…
Si un policier s'était coltiné la tâche de regarder les vidéos de surveillance, ça aurait été pareil, juste plus long. Tant qu'on prends pas la réponse de la machine pour argent comptant, on peut pas vraiment critiquer la chose.
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.
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.
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.
C'est sûr, ça doit jouer… Ils en tiennent quand même une sacrée couche ! J'aurais préféré un article écrit par un technicien, y'a vraiment des choses à dire là dessus. Ici la formulation est gerbante.
https://chiffrer.info/
“Courrier”, pas journal :D
Je croyais que ce site ne faisait pas de statistiques… (trolldi)
Merci ! Ça me pousse à continuer !
un grand merci à toi pour cette source d'information qualitative et d'inspiration quotidienne!
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/
C'est toujours le même problème : tant que les outils numériques restent des aides à la décision, pas de problème. Sauf que ça fini trop souvent en décision (pseudo-)automatisée, où la personne ne prend plus le recul nécessaire pour remettre en question l'avis du système…
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
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 ;-)
Ce que je ne comprends pas, c’est que DNS ou DoH le nom du site web consulte passe toujours en clair (SNI).
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.
Autant bon, la reconnaissance faciale c'est pas ouf, tout ça, et suspecter / accuser juste parce que la machine a dit « c'est lui », c'est limite, autant si l'image est nette et qu'on le reconnaît clairement…
Si un policier s'était coltiné la tâche de regarder les vidéos de surveillance, ça aurait été pareil, juste plus long. Tant qu'on prends pas la réponse de la machine pour argent comptant, on peut pas vraiment critiquer la chose.
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.
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.
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.
Voici le miens :
Excellent article ! Je me demandais justement comment faisais bitwarden pour les mots de passe partagés. Merci !
C'est sûr, ça doit jouer… Ils en tiennent quand même une sacrée couche ! J'aurais préféré un article écrit par un technicien, y'a vraiment des choses à dire là dessus. Ici la formulation est gerbante.
Le problème, c'est que c'est écrit par un éditorialiste économique…
J'utilise aussi le coup de l'alias pour ma part, dont Lord avait parlé sur son propre blog (https://lord.re/posts/62-dotfiles-home-git/).
Ça marche bien, ça évite de s'embêter avec des liens symboliques ou d'avoir un
~/.gitqui vient poser quelques soucis d'utilisation.