Le XKCD ne dit pas que la taille compte, en tout cas ce n'est clairement pas le message principal.
Il dit plutôt qu'il existe une méthode de génération de mot de passe qui aboutit à un résultat plus facile à mémoriser pour un humain et plus difficile à deviner pour un ordinateur que les recommandations "usuelles". Les mots de passe générés avec cette méthode peuvent avoir des tailles très variées (au pifomètre de 16 à 40+ caractères) mais l'entropie (ou la difficulté pour les deviner) est constante.
J'avais retenu des cases du xkcd sur l'entropie : plus c'est long, plus c'est difficile à deviner. Donc je ne comprends pas :
Les mots de passe générés avec cette méthode peuvent avoir des tailles très variées (au pifomètre de 16 à 40+ caractères) mais l'entropie (ou la difficulté pour les deviner) est constante.
Comment l'entropie peut-elle être constante avec un nombre de caractères différents ? La formule pour calculer l'entropie intègre le nombre de caractère :
L étant la longueur du mot de passe (le nombre de caractères)
N étant le nombre possibles de caractères (26 pour l'alphabet latin en minuscules)
D'ailleurs, la page wikipedia donne un tableau avec le nombre de bit d'entropie par symbole pour un nombre de caractères donnés. Par exemple, pour l'alphabet latin en minuscules, c'est 4.7 bits d'entropie par caractère. Ca veut dire 47 bits d'entropie pour 10 caractères.
Cette formule est valable pour des caractères choisis aléatoirement, ce n'est pas le cas ici.
La méthode consiste à choisir 4 mots aléatoires dans une liste de 2048 mots. C'est donc équivalent à choisir 4 caractères aléatoires dans un alphabet virtuel de 2048 caractères. Chacun de ces caractères a une entropie de 11 bits, et l'entropie totale est donc de 44 bits.
La méthode consiste à choisir 4 mots aléatoires dans une liste de 2048 mots
Si l'attaquant ne sait pas que tu utilises cette méthode, et/ou qu'il ne connait pas la liste des 2048 mots (ce qui es en principe le cas, sinon c'est une attaque ciblée sur toi), alors l'entropie est immensément plus élevée.
Posté par NicolasP .
Évalué à 3.
Dernière modification le 28 septembre 2019 à 20:51.
Si l'attaquant ne sait pas que tu utilises cette méthode, et/ou qu'il ne connait pas la liste des 2048 mots (ce qui es en principe le cas, sinon c'est une attaque ciblée sur toi), alors l'entropie est immensément plus élevée.
Cet XKCD propose une méthode qui aurait dû/pu être enseignée au plus grand nombre possible de gens. Si ça avait été effectivement le cas, tu peux être sûr que ça aurait été mis en tête de liste des crackers.
Quant à la liste, l'objectif est quand même que ça soit 2048 mots relativement communs, sinon la partie "déjà mémorisée" ne fonctionne pas. J'ignore combien de mots une personne humaine quelconque connaît, mais ça ne doit pas être des ordres de magnitude au dessus de 2048. Tu multiplies ça par le nombre de langues utilisées si l'attaque porte sur une base internationale et au final tu obtiens quelques bits d'entropie en plus, mais pas "immensément" plus.
J'avais retenu des cases du xkcd sur l'entropie : plus c'est long, plus c'est difficile à deviner
Juste pour préciser : le fait que "plus c'est long, plus c'est difficile à deviner" est vrai (si toutes les autres conditions sont identiques), c'est juste que ce n'est pas le propos de cet xkcd.
C'est bien joli d'avoir une grosse puissance de calcul pour tester des centaines de milliards de combinaisons, mais concrètement on fait comment pour prendre le contrôle du compte mail de quelqu'un si on utilise la force brute ? Il faut bien tester les combinaisons sur le serveur qui héberge le compte. J'imagine que ça prend un peu plus de temps que calculer l'empreinte d'une combinaison puisqu'il faut tenir compte du temps de réponse du serveur.
Ma question est sans doute naïve, mais j'aimerais comprendre.
En général, il y a autre chose à côté, par exemple tu as récupéré la base de données des hash sur le site (ou un autre site, en partant du principe que ta cible a le même mot de passe).
ça veut donc dire que les sites nous demandent d'utiliser des mots de passe compliqués à retenir parce qu'ils ne veulent pas se fatiguer à se protéger eux-mêmes ?
Même des sites très gros publics et donc - probablement - très sécurisés se sont fait voler des listes de hash de mots de passe. D'un point de vue de sécurité, il faut supposer que tous les autres composants ont failli pour spécifier la sécurité du composant n+1 que tu es en train de définir.
Dans le cas où tout a failli (ici : "la base de données a fuité"), la dernière protection qui reste est le coût de vérification du hash.
Si je poussais ton raisonnement, je pourrais dire qu'un mot de passe de 3 chiffres suffit, puisque, après tout, les sites sont censés aussi protéger contre les tentatives de brute-force (ce que la plupart font). Ben … tu peux raisonner comme ça mais je donne pas cher de tes identifiants.
On trouve encore des sites qui te demandent plein de contraintes sur le mot de masse (longueur, types de caractères) et vont t'envoyer ce mot de passe en clair par e-mail. Parfois même quand tu demandes à récupérer le mot de passe…
(Au cas où on me le demanderait, je n'ai pas noté les noms les dernières fois où ça m'est arrivé)
Si je poussais ton raisonnement, je pourrais dire qu'un mot de passe de 3 chiffres suffit, puisque, après tout, les sites sont censés aussi protéger contre les tentatives de brute-force (ce que la plupart font). Ben … tu peux raisonner comme ça mais je donne pas cher de tes identifiants.
Je voyais ça plutôt comme un aveu que quand un site se prétend sécurisé, et bien il est prudent de ne pas le croire.
J'en ai fait l'expérience ce matin avec le site de ma mutuelle : elle m'a envoyé un courriel pour me proposer d'ouvrir mon "espace personnel sécurisé" et passer par la même occasion aux courriers dématérialisés. Il faut cliquer sur un lien pour accéder à la page de création de l'espace personnel. Et là Firefox se met dans tous ses états : le certificat n'est pas valide pour le site en question et si on regarde le certificat Firefox dit qu'il ne peut pas le vérifier car l'émetteur est inconnu.
Je les ai prévenus qu'il y a comme un souci, mais je pense que je vais rester aux courriers papier encore un moment.
Il faut bien tester les combinaisons sur le serveur qui héberge le compte.
L'auteur du billet répond à cette objection dans les commentaires. Ça ne change rien au fond de l'argument, ajouter des caractères spéciaux augmente beaucoup moins l'entropie que de rajouter un caractère alphanumérique, et l'obligation de caractères spéciaux dans les mdp est juste chiante et totalement injustifiée.
La seule chose que change le mode d'accès à la bdd (accès à la bdd de hash sur un disque local ou via l'interrogation du site), c'est un facteur à multiplier au coût. Mais demander un caractère spécial reste aussi stupide dans tous les cas.
De toutes manières, si ton seul moyen de tester un mdp c'est d'interroger le serveur, la brute force est inefficace, même si le mdp fait 4 caractères. L'objectif reste de multiplier les niveaux de sécurité…
ajouter des caractères spéciaux augmente beaucoup moins l'entropie que de rajouter un caractère alphanumérique
Est-ce que tu ne voulais pas écrire : "ajouter des caractères spéciaux au catalogue des caractères autorisés augmente beaucoup moins l'entropie que allonger d'un caractère le mot de passe à tester" ?
J'imagine que le programme de force brute ne connaît pas a priori la liste des caractères possibles du mot de passe à tester. Il va donc faire l'hypothèse la plus large et on se retrouve donc avec avec un jeu de caractères fixe indépendant des recommandations faites à l'utilisateur pour construire son mot de passe. Comme en fait la liste des caractères, du point de vue du programme de crackage, est la même pour tout le monde, il ne reste que la longueur du mot de passe pour renforcer sa robustesse.
Est-ce que tu ne voulais pas écrire : "ajouter des caractères spéciaux au catalogue des caractères autorisés augmente beaucoup moins l'entropie que allonger d'un caractère le mot de passe à tester" ?
Euh oui. J'avoue que la nuance que je fais entre "ajouter" et "rajouter" est peut-être subtile et personnelle :-)
Il va donc faire l'hypothèse la plus large et on se retrouve donc avec avec un jeu de caractères fixe indépendant des recommandations
Si j'étais un vilain craker, je crois que je commencerais par les jeux de caractères les plus simples avant d'ajouter caractère par caractère les moins fréquents. En fait, le plus simple, c'est probablement d'utiliser les fréquences des caractères dans les tables de mdp pour les ajouter dans le bon ordre.
Le pire dans l'histoire, c'est peut-être que les recommandations excluent un certain nombre de mdp des possibles (si au moins 8 caractères, pas besoin de tester les petits mdp), et du coup le gain d'entropie est encore plus faible.
De toutes manières, ça ne peut pas durer indéfiniment ces histoires de mdp. Si pour se préserver des attaques il faut fournir des suites de 57 caractères aléatoires, le principe même du mdp est foireux.
yep, a supposer qu'on réclame un mot de passe de 8 caractères minimum avec au moins 1 chiffre, au moins 1 majuscule, et au moins 1 caractères spécial, au moins une minuscule, tu peux largement écrémer ta recherche; en plus pour plus de facilité je me limiterai aux caractères accessible en qwerty
ce qui fait que sur ton mdp, tu as au moins 4 caractères qui sont dans un jeu restreint; le pire étant sans doute d'imposer un chiffre.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Je pense que tout dépend de la qualité des heuristiques qui déterminent l'ordre dans lesquels les mdp sont testés. En théorie, l'information qu'il y a au moins un chiffre dans un mdp de 8 caractères ne fait pas terriblement diminuer l'entropie du mdp (un peu, c'est indéniable, mais pas tant que ça). Maintenant, en pratique, il y a probablement énormément de chances qu'il n'y ait en effet qu'un seul chiffre, et qu'il soit en dernière position. Si ta routine de test prend en compte ces facteurs psychologiques, alors il y a fort à parier que tes instructions sur la complexité des mots de passe vont en fait diminuer leur entropie.
Mais dans le fond, je crois qu'on regarde le doigt quand le sage montre la lune. La réalité, c'est que la protection par mdp est illusoire ; pour qu'elle soit efficace, il faudrait que les mdp soient aléatoires et spécifiques (donc, impossible de s'en souvenir efficacement), et/ou il faudrait confier leur stockage et leur disponibilité en ligne à des logiciels et à des tiers (donc, risque de bugs ou de fuites mal intentionnées), et/ou il faudrait les stocker physiquement dans un coffre (donc risque supplémentaire). Et rien de tout ça ne garantit qu'il ne sera pas trivial de les craquer d'ici quelques années (faille dans le protocole ou progrès matériels), et au pire du pire, si le système est réellement très robuste, il suffit de jouer de malchance (le coffre fort et le mec qui connait les mdp sont dans la même pièce, et paf la météorite?) pour que les données soient perdues (en gros, plus la protection est efficace, et plus le risque de perdre les données pour de vrai est important). À force de ne considérer que les aspects techniques du problème (qui mène à des histoires de double identification ou des protocoles de plus en plus complexes et parfois risqués pour récupérer un mdp oublié), on oublie de se poser de la question de la valeur des données protégées et des niveaux de risques acceptables. Je veux dire, ça n'est jamais agréable de se faire cambrioler, et oui, il existe des niveaux de protection meilleurs que ce que la plupart des gens ont à proposer (des fenêtres en bois? WTF, une technologie du XVIIIe siècle!). Pourtant, peu de gens installent des barreaux ou murent leurs fenêtre, pour la simple raison qu'ils balancent les coûts et les bénéfices. Bien sûr, ça m'embêterait de me faire pomper mes photos de vacances ou les données du boulot, mais ça m'embêterait encore plus de les perdre définitivement, et ça m'embête de perdre 10 minutes à chaque fois que je veux y accéder d'une machine qui n'est pas la mienne parce que le lien de modification du mot de passe a été envoyé à une adresse email dont je ne connais plus le mot de passe de 27 caractères aléatoires… Du coup, par exemple, est-ce que ça serait problématique si le mdp pour accéder à mon compte linuxfr comportait 4 caractères? Quelles seraient les conséquences si je me le faisais pirater? Quelqu'un pourrait se faire passer pour moi et troller à ma place? Brrr, j'en ai froid dans le dos…
Your Pa$$word doesn't matter est un article écrit par un membre de l'équipe sécurité d'Azure. En résumé, dans la vraie vie, la plupart des attaques qui ont réussi ne l'ont pas été à cause d'une faiblesse du mot de passe, mais à cause d'un autre facteur. Et donc si on veut vraiment se protéger, ce n'est pas avec des règles sur les mots de passe (que ça soit longueur ou complexité) mais avec de l'authentification multi facteurs.
De manière générale, imposer des dates d'expiration ou des contraintes sur les mots de passe n'est plus à l'ordre du jour (recommandations du NIST). J'ai l'impression que c'est juste l'inertie qui fait qu'on voit encore des règles de ce type.
# Développeurs, vous devriez avoir honte
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Déjà, pour commencer.
[^] # Re: Développeurs, vous devriez avoir honte
Posté par David Marec . Évalué à 3.
pour continuer.
# La taille compte
Posté par nico4nicolas . Évalué à 2.
Pour résumer l'article : la taille a de l'importance (size matters). Pour exprimer la même chose, je préfère le xkcd.
[^] # Re: La taille compte
Posté par NicolasP . Évalué à 3.
Le XKCD ne dit pas que la taille compte, en tout cas ce n'est clairement pas le message principal.
Il dit plutôt qu'il existe une méthode de génération de mot de passe qui aboutit à un résultat plus facile à mémoriser pour un humain et plus difficile à deviner pour un ordinateur que les recommandations "usuelles". Les mots de passe générés avec cette méthode peuvent avoir des tailles très variées (au pifomètre de 16 à 40+ caractères) mais l'entropie (ou la difficulté pour les deviner) est constante.
[^] # Re: La taille compte
Posté par nico4nicolas . Évalué à 4.
J'avais retenu des cases du xkcd sur l'entropie : plus c'est long, plus c'est difficile à deviner. Donc je ne comprends pas :
Comment l'entropie peut-elle être constante avec un nombre de caractères différents ? La formule pour calculer l'entropie intègre le nombre de caractère :
L étant la longueur du mot de passe (le nombre de caractères)
N étant le nombre possibles de caractères (26 pour l'alphabet latin en minuscules)
D'ailleurs, la page wikipedia donne un tableau avec le nombre de bit d'entropie par symbole pour un nombre de caractères donnés. Par exemple, pour l'alphabet latin en minuscules, c'est 4.7 bits d'entropie par caractère. Ca veut dire 47 bits d'entropie pour 10 caractères.
Qu'est ce que je n'ai pas compris ?
[^] # Re: La taille compte
Posté par NicolasP . Évalué à 5.
Cette formule est valable pour des caractères choisis aléatoirement, ce n'est pas le cas ici.
La méthode consiste à choisir 4 mots aléatoires dans une liste de 2048 mots. C'est donc équivalent à choisir 4 caractères aléatoires dans un alphabet virtuel de 2048 caractères. Chacun de ces caractères a une entropie de 11 bits, et l'entropie totale est donc de 44 bits.
[^] # Re: La taille compte
Posté par Kerro . Évalué à 5.
Si l'attaquant ne sait pas que tu utilises cette méthode, et/ou qu'il ne connait pas la liste des 2048 mots (ce qui es en principe le cas, sinon c'est une attaque ciblée sur toi), alors l'entropie est immensément plus élevée.
[^] # Re: La taille compte
Posté par NicolasP . Évalué à 3. Dernière modification le 28 septembre 2019 à 20:51.
Cet XKCD propose une méthode qui aurait dû/pu être enseignée au plus grand nombre possible de gens. Si ça avait été effectivement le cas, tu peux être sûr que ça aurait été mis en tête de liste des crackers.
Quant à la liste, l'objectif est quand même que ça soit 2048 mots relativement communs, sinon la partie "déjà mémorisée" ne fonctionne pas. J'ignore combien de mots une personne humaine quelconque connaît, mais ça ne doit pas être des ordres de magnitude au dessus de 2048. Tu multiplies ça par le nombre de langues utilisées si l'attaque porte sur une base internationale et au final tu obtiens quelques bits d'entropie en plus, mais pas "immensément" plus.
[^] # Re: La taille compte
Posté par NicolasP . Évalué à 3.
Juste pour préciser : le fait que "plus c'est long, plus c'est difficile à deviner" est vrai (si toutes les autres conditions sont identiques), c'est juste que ce n'est pas le propos de cet xkcd.
# Il y a un truc qui m'échappe
Posté par Jean-Baptiste Faure . Évalué à 4.
C'est bien joli d'avoir une grosse puissance de calcul pour tester des centaines de milliards de combinaisons, mais concrètement on fait comment pour prendre le contrôle du compte mail de quelqu'un si on utilise la force brute ? Il faut bien tester les combinaisons sur le serveur qui héberge le compte. J'imagine que ça prend un peu plus de temps que calculer l'empreinte d'une combinaison puisqu'il faut tenir compte du temps de réponse du serveur.
Ma question est sans doute naïve, mais j'aimerais comprendre.
[^] # Re: Il y a un truc qui m'échappe
Posté par flan (site web personnel) . Évalué à 6.
En général, il y a autre chose à côté, par exemple tu as récupéré la base de données des hash sur le site (ou un autre site, en partant du principe que ta cible a le même mot de passe).
[^] # Re: Il y a un truc qui m'échappe
Posté par Jean-Baptiste Faure . Évalué à 4.
ça veut donc dire que les sites nous demandent d'utiliser des mots de passe compliqués à retenir parce qu'ils ne veulent pas se fatiguer à se protéger eux-mêmes ?
[^] # Re: Il y a un truc qui m'échappe
Posté par Samuel (site web personnel) . Évalué à 3.
Même des sites très gros publics et donc - probablement - très sécurisés se sont fait voler des listes de hash de mots de passe. D'un point de vue de sécurité, il faut supposer que tous les autres composants ont failli pour spécifier la sécurité du composant n+1 que tu es en train de définir.
Dans le cas où tout a failli (ici : "la base de données a fuité"), la dernière protection qui reste est le coût de vérification du hash.
Si je poussais ton raisonnement, je pourrais dire qu'un mot de passe de 3 chiffres suffit, puisque, après tout, les sites sont censés aussi protéger contre les tentatives de brute-force (ce que la plupart font). Ben … tu peux raisonner comme ça mais je donne pas cher de tes identifiants.
[^] # Re: Il y a un truc qui m'échappe
Posté par ted (site web personnel) . Évalué à 3.
On trouve encore des sites qui te demandent plein de contraintes sur le mot de masse (longueur, types de caractères) et vont t'envoyer ce mot de passe en clair par e-mail. Parfois même quand tu demandes à récupérer le mot de passe…
(Au cas où on me le demanderait, je n'ai pas noté les noms les dernières fois où ça m'est arrivé)
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Il y a un truc qui m'échappe
Posté par Jean-Baptiste Faure . Évalué à 3.
Je voyais ça plutôt comme un aveu que quand un site se prétend sécurisé, et bien il est prudent de ne pas le croire.
J'en ai fait l'expérience ce matin avec le site de ma mutuelle : elle m'a envoyé un courriel pour me proposer d'ouvrir mon "espace personnel sécurisé" et passer par la même occasion aux courriers dématérialisés. Il faut cliquer sur un lien pour accéder à la page de création de l'espace personnel. Et là Firefox se met dans tous ses états : le certificat n'est pas valide pour le site en question et si on regarde le certificat Firefox dit qu'il ne peut pas le vérifier car l'émetteur est inconnu.
Je les ai prévenus qu'il y a comme un souci, mais je pense que je vais rester aux courriers papier encore un moment.
[^] # Re: Il y a un truc qui m'échappe
Posté par arnaudus . Évalué à 3.
L'auteur du billet répond à cette objection dans les commentaires. Ça ne change rien au fond de l'argument, ajouter des caractères spéciaux augmente beaucoup moins l'entropie que de rajouter un caractère alphanumérique, et l'obligation de caractères spéciaux dans les mdp est juste chiante et totalement injustifiée.
La seule chose que change le mode d'accès à la bdd (accès à la bdd de hash sur un disque local ou via l'interrogation du site), c'est un facteur à multiplier au coût. Mais demander un caractère spécial reste aussi stupide dans tous les cas.
De toutes manières, si ton seul moyen de tester un mdp c'est d'interroger le serveur, la brute force est inefficace, même si le mdp fait 4 caractères. L'objectif reste de multiplier les niveaux de sécurité…
[^] # Re: Il y a un truc qui m'échappe
Posté par Jean-Baptiste Faure . Évalué à 2.
Est-ce que tu ne voulais pas écrire : "ajouter des caractères spéciaux au catalogue des caractères autorisés augmente beaucoup moins l'entropie que allonger d'un caractère le mot de passe à tester" ?
J'imagine que le programme de force brute ne connaît pas a priori la liste des caractères possibles du mot de passe à tester. Il va donc faire l'hypothèse la plus large et on se retrouve donc avec avec un jeu de caractères fixe indépendant des recommandations faites à l'utilisateur pour construire son mot de passe. Comme en fait la liste des caractères, du point de vue du programme de crackage, est la même pour tout le monde, il ne reste que la longueur du mot de passe pour renforcer sa robustesse.
[^] # Re: Il y a un truc qui m'échappe
Posté par arnaudus . Évalué à 3.
Euh oui. J'avoue que la nuance que je fais entre "ajouter" et "rajouter" est peut-être subtile et personnelle :-)
Si j'étais un vilain craker, je crois que je commencerais par les jeux de caractères les plus simples avant d'ajouter caractère par caractère les moins fréquents. En fait, le plus simple, c'est probablement d'utiliser les fréquences des caractères dans les tables de mdp pour les ajouter dans le bon ordre.
Le pire dans l'histoire, c'est peut-être que les recommandations excluent un certain nombre de mdp des possibles (si au moins 8 caractères, pas besoin de tester les petits mdp), et du coup le gain d'entropie est encore plus faible.
De toutes manières, ça ne peut pas durer indéfiniment ces histoires de mdp. Si pour se préserver des attaques il faut fournir des suites de 57 caractères aléatoires, le principe même du mdp est foireux.
[^] # Re: Il y a un truc qui m'échappe
Posté par fearan . Évalué à 1.
yep, a supposer qu'on réclame un mot de passe de 8 caractères minimum avec au moins 1 chiffre, au moins 1 majuscule, et au moins 1 caractères spécial, au moins une minuscule, tu peux largement écrémer ta recherche; en plus pour plus de facilité je me limiterai aux caractères accessible en qwerty
ce qui fait que sur ton mdp, tu as au moins 4 caractères qui sont dans un jeu restreint; le pire étant sans doute d'imposer un chiffre.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Il y a un truc qui m'échappe
Posté par arnaudus . Évalué à 5.
Je pense que tout dépend de la qualité des heuristiques qui déterminent l'ordre dans lesquels les mdp sont testés. En théorie, l'information qu'il y a au moins un chiffre dans un mdp de 8 caractères ne fait pas terriblement diminuer l'entropie du mdp (un peu, c'est indéniable, mais pas tant que ça). Maintenant, en pratique, il y a probablement énormément de chances qu'il n'y ait en effet qu'un seul chiffre, et qu'il soit en dernière position. Si ta routine de test prend en compte ces facteurs psychologiques, alors il y a fort à parier que tes instructions sur la complexité des mots de passe vont en fait diminuer leur entropie.
Mais dans le fond, je crois qu'on regarde le doigt quand le sage montre la lune. La réalité, c'est que la protection par mdp est illusoire ; pour qu'elle soit efficace, il faudrait que les mdp soient aléatoires et spécifiques (donc, impossible de s'en souvenir efficacement), et/ou il faudrait confier leur stockage et leur disponibilité en ligne à des logiciels et à des tiers (donc, risque de bugs ou de fuites mal intentionnées), et/ou il faudrait les stocker physiquement dans un coffre (donc risque supplémentaire). Et rien de tout ça ne garantit qu'il ne sera pas trivial de les craquer d'ici quelques années (faille dans le protocole ou progrès matériels), et au pire du pire, si le système est réellement très robuste, il suffit de jouer de malchance (le coffre fort et le mec qui connait les mdp sont dans la même pièce, et paf la météorite?) pour que les données soient perdues (en gros, plus la protection est efficace, et plus le risque de perdre les données pour de vrai est important). À force de ne considérer que les aspects techniques du problème (qui mène à des histoires de double identification ou des protocoles de plus en plus complexes et parfois risqués pour récupérer un mdp oublié), on oublie de se poser de la question de la valeur des données protégées et des niveaux de risques acceptables. Je veux dire, ça n'est jamais agréable de se faire cambrioler, et oui, il existe des niveaux de protection meilleurs que ce que la plupart des gens ont à proposer (des fenêtres en bois? WTF, une technologie du XVIIIe siècle!). Pourtant, peu de gens installent des barreaux ou murent leurs fenêtre, pour la simple raison qu'ils balancent les coûts et les bénéfices. Bien sûr, ça m'embêterait de me faire pomper mes photos de vacances ou les données du boulot, mais ça m'embêterait encore plus de les perdre définitivement, et ça m'embête de perdre 10 minutes à chaque fois que je veux y accéder d'une machine qui n'est pas la mienne parce que le lien de modification du mot de passe a été envoyé à une adresse email dont je ne connais plus le mot de passe de 27 caractères aléatoires… Du coup, par exemple, est-ce que ça serait problématique si le mdp pour accéder à mon compte linuxfr comportait 4 caractères? Quelles seraient les conséquences si je me le faisais pirater? Quelqu'un pourrait se faire passer pour moi et troller à ma place? Brrr, j'en ai froid dans le dos…
# L'utilité des règles de mots de passe dans la vraie vie
Posté par NicolasP . Évalué à 7.
Your Pa$$word doesn't matter est un article écrit par un membre de l'équipe sécurité d'Azure. En résumé, dans la vraie vie, la plupart des attaques qui ont réussi ne l'ont pas été à cause d'une faiblesse du mot de passe, mais à cause d'un autre facteur. Et donc si on veut vraiment se protéger, ce n'est pas avec des règles sur les mots de passe (que ça soit longueur ou complexité) mais avec de l'authentification multi facteurs.
De manière générale, imposer des dates d'expiration ou des contraintes sur les mots de passe n'est plus à l'ordre du jour (recommandations du NIST). J'ai l'impression que c'est juste l'inertie qui fait qu'on voit encore des règles de ce type.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.