Vous n'avez pas besoin de forcer brutalement un hachage pour voler un mot de passe. Un site Web peut être compromis par un attaquant afin qu'il puisse lire les mots de passe directement à partir du formulaire de connexion, en texte brut. Ou le propriétaire du site Web pourrait faire cela, il pourrait toujours le faire s'il le voulait, c'est à vous de décider si vous faites confiance au propriétaire ou non (vous ne voudriez pas utiliser le même mot de passe sur Facebook et SomeBlackHatCommunity dot com). De plus, il y a toujours le bon vieux surf d'épaule pour voler des mots de passe. Un mot de passe est comme une clé, et en utilisant le même mot de passe, vous donnez en fait la même clé à différentes portes à différentes personnes. Vous pouvez voir que ce n'est jamais une bonne idée.

Donc, vous ne devriez jamais utiliser le même mot de passe à différents endroits, à moins que ce mot de passe ne protège les mêmes données ou ne vous donne les mêmes privilèges, donc par exemple, je pense que vous pouvez utiliser le même mot de passe pour protéger vos sauvegardes.

TL; DR: Je n'ai pas besoin de récupérer VOTRE mot de passe, je dois juste trouver une chaîne qui génère le même hachage, et comme vous ne contrôlez pas le hachage que le développeur du site utilise jusqu'à ce qu'ils utilisent tous un hachage sécurisé , ça n'aide pas autant que ça coûte. Et si je suis après vous , je continue de pirater les sites Web que vous utilisez jusqu'à ce que j'en trouve un faible. Ou j'utilise une autre méthode.

XKCD pertinent:

https://www.xkcd.com/936/

Parce que s'il n'y a pas de XKCD pertinent , il y en aura bientôt.

La réutilisation des mots de passe présente un risque terrible pour les utilisateurs car en cas de violation de données,

Uniquement si ce mot de passe protège quelque chose qui compte.

Pour une utilisation générale du forum Internet, j'ai un nom de guerre avec sa propre adresse e-mail et quatre ou cinq mots de passe pour tout.

Ces mots de passe ne protègent rien . Même compromettre le compte de messagerie derrière eux ne vous procure rien d'autre que la possibilité de rendre mon nom de guerre plus idiot qu'il n'en a déjà l'air.

les mots de passe n'étant pas stockés de manière suffisamment sécurisée,

Le mot de passe n'est pas stocké. Nous y reviendrons.

cela signifie que, par défaut, tous les autres services pour lesquels ils utilisent ce mot de passe sont également compromis.

Pour être plus précis, cela devrait être formulé:

... cela signifie que, par défaut, tous les autres services utilisant cette adresse e-mail et le mot de passe doivent être considérés compromis ET si l'attaquant connaît votre autre adresse e-mail, tout ce qui utilise ce mot de passe doit être pris en compte ...

Identité (à ces fins) sont ce que vous êtes (adresse e-mail) plus ce que vous savez (mot de passe).

Si je sais que vous êtes "joebob@gmail.com" sur somerandomforum.com et wellsfargo.com ET vous utilisez le même mot de passe pour les trois que vous êtes arrosé.

Mais si vous utilisez "joebob@gmail.com" sur les forums Web, Azxdreuwa@yahoo.com pour votre usage "personnel" et "Alexander.Scott@yourowndomain.com" pour un usage professionnel, alors c'est extrêmement difficile pour un attaquant algorithmique pour les trier.

Généralement, avec ces violations, ils stockent le mot de passe en utilisant uniquement un algorithme de hachage comme SHA-1, ou même encore MD5 dans certains cas récemment

Je vous connais sachez cela, et je suis terriblement pédant, mais généralement nous ne stockons pas les mots de passe . S'il s'agit de SHA-1, ou MD5, ou de tout autre hachage (y compris la «crypt» pauvre et morte ou la plus récente ininterrompue du bloc), il n'y a aucun aller-retour fiable prouvable entre le hachage et le mot de passe.

Vous NE POUVEZ PAS et n'obtenez pas de eaf4c33ae978d3f2852021214a061534 à "Fred est mort". Vous pourriez être en mesure de créer deux ou plusieurs chaînes de longueur indéterminée pour ce même hachage. Ce que vous pouvez faire, c'est générer des chaînes jusqu'à ce qu'elles correspondent. C'est différent et c'est une différence CRITIQUE. Et c'est essentiel pour cela aussi.

(qui n'ont jamais été conçus pour stocker les mots de passe en toute sécurité), ce qui permet aux attaquants de forcer facilement les mots de passe en utilisant uniquement la puissance de hachage brute du GPU.

Quelle perte totale de temps et d'électricité qui serait BEAUCOUP mieux dépensé $ {WHATEVER} pour extraire des pièces de monnaie.

De toute façon, vous ne reconstruisez pas le hachage, vous continuez à lancer des chaînes sur l'algorithme jusqu'à ce que vous obteniez une correspondance

Les tables arc-en-ciel précalculées sont BEAUCOUP plus rapides lorsque les cinq millions d'e-mails: name: password tuples que vous venez d'extraire de BigWebSiteInc, et que vous allez BEAUCOUP plus de résultats beaucoup plus vite.

Et oui, sachez que les GPU peuvent calculer cela très rapidement, mais les recherches sont BIEN plus rapides, et je vais vouloir casser BEAUCOUP de mots de passe, pas seulement le vôtre.

Si je veux VOS identifiants, j'ai d'autres moyens de les obtenir et si je les veux assez ... oui, ce n'est probablement pas un forum que Stack Exchange souhaite héberger. La sécurité comporte de nombreux aspects et la cryptographie n'en protège que certains.

Si une personne devait créer un mot de passe correctement aléatoire d'une longueur suffisante (par exemple 100+) d'une entropie très suffisante qui est mélangée avec de nombreux types de

Histoire vraie. Il y a un peu plus de dix ans, j'étais dans la réserve de l'armée américaine, et ils ont (avaient?) Un système où votre carte d'identité militaire faisait partie de vos informations d'identification pour votre compte réseau. Pour vous connecter à la plupart de leurs ordinateurs, vous deviez mettre votre carte d'identité militaire dans un lecteur de carte à puce et entrer votre "code PIN".

À un moment donné, j'ai eu une nouvelle carte d'identité, ce qui a nécessité une nouvelle ÉPINGLE. Je suis donc allé à l'emplacement d'entrée de la broche, et j'ai mis un numéro IIRC à 10 chiffres dans le clavier, puis je l'ai remis. Il a dit que mon code PIN correspondait et je suis parti.

Je suis revenu à mon unité et j'ai essayé de me connecter. Échec.

J'y suis retourné. Quelques fois. Nous étions confus. Ensuite, j'ai raccourci le code PIN et cela a fonctionné.

Il y avait une limite de 8 ou 9 caractères pour le NIP (ou autre. C'était $ MY_NUM-2). Le premier système d'entrée rejetait silencieusement les numéros supplémentaires. Le second n'était pas, conduisant à une discordance. (Ou l'inverse)

ISTR il y a des trucs dans le readme SAMBA à propos de la première version de la base de données de mots de passe de NT stockant le hachage en 2 parties parce que l'ancien truc LANMAN (??) ne contenait que des mots de passe à 8 caractères. Je ne sais pas comment cela fonctionnait.

Quoi qu'il en soit, le flux de travail de l'écran de saisie au stockage des mots de passe aura parfois un nombre limité de caractères, d'autres non. Et cela peut changer à mesure que divers sites Web modifient leur logiciel. Heck, cela pourrait être différent sur différentes parties d'un système fédéré. Vous voulez vous assurer de ne pas dépasser leurs attentes.

symboles, chiffres et lettres; dans le cas où leur machine n'est pas compromise dans le sens où un keylogger est installé ou similaire, et que toutes leurs sessions de navigation sont effectuées via un tunnel crypté, y a-t-il un risque à réutiliser ce mot de passe pour plusieurs sites Web si cela ne peut jamais être craqué au cours de leur vie si une violation de données s'est produite sur l'un des services qu'ils utilisent?

Honnêtement, pour les applications de haute sécurité (par exemple, la protection des clés SSH, etc.), j'utilise les premières strophes de quelques chansons bien connues. Au moins l'un d'entre eux a une faute d'orthographe accidentelle qui est définitivement fixée dans ma brane.

Le fait est que si je regarde un ID: hachage pw dans un magasin de mots de passe (fichier, base de données, peu importe), je VEUX le plus facile à casser que je puisse. Je ne veux pas du gars qui utilise une sorte de magasin de clés fort et qui a un mot de passe différent pour tous les autres sites, je veux juste le fruit à portée de main. Ce sont les plus susceptibles de réutiliser les mots de passe.

Donc oui, cela rend votre mot de passe plus sécurisé, modulo quelques choses.

Vous ne pouvez pas choisir le hachage utilisé à l'extrémité distante, et tant que les gens utilisent des hachages "cassés" (md5, SHA-1, etc.) vous pouvez obtenir plus de une chaîne correspondant au hachage. Et tant qu'un site Web que vous utilisez continue de stocker les mots de passe dans un hachage incorrect, vous êtes vulnérable.

C'est pourquoi j'étais pédant. Nous ne stockons pas les mots de passe, nous stockons un hash du mot de passe, et je n'ai pas besoin de récupérer VOTRE mot de passe, je dois juste trouver une chaîne qui génère le même hachage.

Il se peut que votre chaîne de 100 caractères composée par la sortie du meilleur générateur de nombres aléatoires blanchis arrive simplement pour correspondre au hachage de "Fred est mort" et alors vous perdu.

Cela s'ajoute au fait que quelqu'un met une caméra là où il peut vous regarder taper, exécutant une attaque MITM sur votre session SSL (ce qui représente environ la moitié des grandes entreprises dans lesquelles j'ai travaillé ces dernières années - ils le font sur leur serveur proxy pour faire DLP), piratant le site Web pour mettre du code supplémentaire dans leur page de connexion, ou l'un d'une douzaine d'autres hacks.

Ou simplement mettre un pistolet sur votre genou. Ou des méthodes plus macabres.

Utiliser des mots de passe jetables pour les données jetables, plusieurs «identités» en ligne et un stockage de clés suffisamment sécurisé pour les éléments importants est probablement la meilleure façon de procéder. C'est une sorte de "défense en profondeur", et c'est assez facile à faire (diable, je peux le faire, ça ne peut pas être si difficile).

Pour aborder quelque chose, @IMSoP fait apparaître un commentaire.

Le hachage réel stocké est généralement le mot de passe + un hachage, il est donc peu probable que votre forum Web non sécurisé préféré et votre banque utilisent le même algorithme de hachage et le même sel. Ils pourraient, mais peu probable.

Cependant, un point secondaire est que pour TOUT site utilisant un hachage non sécurisé - et c'est BEAUCOUP d'entre eux (voir une autre histoire vraie ci-dessous) un attaquant peut récupérer une chaîne qui hache ce qui est stocké, puis interagissez avec ce site comme vous.

Cela évite le problème de la "réutilisation du mot de passe", mais résout le problème du mot de passe super long. C'est comme dans ... euh ... d'autres domaines de la vie. Une certaine quantité est bonne, plus c'est mieux, mais trop causera des problèmes.

En ce qui concerne l'utilisation de hachages «non sécurisés», les entreprises ont tendance à s'inquiéter le plus des poursuites judiciaires, et secondairement de la publicité, et enfin de la sécurité réelle. Un de mes amis a un brevet sur un mécanisme de stockage assez sécurisé qui augmenterait considérablement la sécurité des ordinateurs portables et des ordinateurs de bureau (entre autres). Il a essayé d'impliquer quelques grandes entreprises dans ce domaine, et toutes celles qu'il a contactées ont indiqué la même chose - que leur sécurité actuelle répond à la fois aux "pratiques courantes de l'industrie" et aux normes juridiques, de sorte qu'elles ne sont pas intéressées par des dépenses au-delà de cela. . Ils sont, à leur avis, «à l'épreuve des poursuites» et sont beaucoup moins préoccupés par la publicité à cause de cela.

C'est pourquoi les banques ont décidé que poser une question stupide était une "authentification à trois facteurs" et d'autres pratiques de sécurité clairement discutables.

Cela signifie que leurs algorithmes de hachage sont ceux livrés avec le système d'exploitation lors de son installation . Parce que c'est la «pratique courante de l'industrie».

Un mot de passe de 16 ou 20 caractères stocké dans un outil de mot de passe sécurisé est tout aussi bon qu'un mot de passe de 100 caractères dans ces conditions .

Pour revenir en arrière, je ne suis pas aussi opposé à la réutilisation des mots de passe que certains ici - j'ai plusieurs ordinateurs personnels sur lesquels je partage le même mot de passe (et quelques-uns qui sont différents), mais je ne jamais dupliquer certains d'entre eux (mes comptes de messagerie personnels, professionnels et professionnels, mots de passe bancaires, etc.). Cela ne vaut tout simplement pas le risque.

Généralement , un site Web utilise une fonction de hachage faible pour stocker les mots de passe, mais êtes-vous prêt à dire qu'aucun des sites Web que vous utilisez ne stockera le mot de passe en utilisant le cryptage, ou pire, en texte brut?

En réutilisant un mot de passe, votre sécurité est aussi forte que celle du plus faible des sites sur lesquels vous l'utilisez. Peu importe la durée ou la complexité de votre mot de passe si un attaquant peut simplement le lire dans le journal de changement de mot de passe d'un serveur mal conçu.

Vous supposez un système parfait avec

dans le cas où leur machine n'est pas compromise dans le sens où un keylogger est installé ou autre, et toutes leurs sessions de navigation se font via un tunnel crypté,

ou du moins je suppose que vous le faites - ce tunnel crypté ferait mieux d'être bon.

Mais vous n'avez aucun contrôle sur le serveur qui détient votre mot de passe . Même les entreprises qui devraient être mieux informées ont récemment foiré leur système de mot de passe: GitHub et Twitter ont des mots de passe en texte brut enregistrés en interne ou mis en cache.

Il n'y a pas non plus avantage - vous ne vous souviendrez jamais de ce mot de passe, vous le stockez donc dans un gestionnaire de mots de passe. À ce stade, vous pouvez également utiliser des mots de passe uniques (qui sont plus courts au cas où vous auriez à les retaper).

Vous pouvez trouver différentes solutions pour le hachage de mot de passe sur les sites Web: des fonctions mémoire comme Argon2 ou Scrypt, du matériel personnalisé vulnérable, mais au moins des fonctions salées comme PBKDF2, des fonctions de hachage simples sans sel et facteur de travail et - malheureusement pas si rare - également stockage ou transmission de mots de passe en clair.

Une fois qu'un mot de passe est compromis, il peut apparaître dans les listes de mots de passe utilisées pour attaquer d'autres sites Web. Le problème avec la réutilisation des mots de passe est que la sécurité est définie par la fonction la plus faible et s'il y a du stockage en texte clair quelque part, la sécurité est tombée à zéro, même pour les mots de passe réellement sécurisés.

Il y a un risque à réutiliser des mots de passe même si votre mot de passe est très fort. Si un site Web qui stocke des mots de passe en texte brut est violé, votre mot de passe fort sera disponible pour les attaquants sans avoir besoin de forcer brutalement les hachages. En d'autres termes, si vous utilisez votre mot de passe très fort sur un site Web qui stocke les mots de passe en texte clair, la force de votre mot de passe ne sert à rien.

Malheureusement, de nombreux sites Web stockent les mots de passe en texte clair et ce n'est pas toujours immédiatement il est évident qu'un site Web le fasse ou non. Il n'est donc pas prudent de réutiliser un mot de passe très fort en supposant que le hachage ne sera pas forcé brutalement, car il peut encore être stocké (et violé) en texte brut.

TL; DR : le craquage des mots de passe n'est pas la seule considération de sécurité avec la réutilisation des mots de passe. Partager un mot de passe avec plusieurs sites signifie qu'en cas de problème avec les autres sites / votre ordinateur / votre réseau en dehors des mots de passe crackables, vous êtes toujours à risque.

Quelques bonnes réponses ici déjà mais juste pour ajouter quelques considérations supplémentaires et un résumé.

Votre question suppose de nombreuses déclarations que la plupart des gens ne contrôleront pas:

leur machine n'est pas compromis dans le sens où un keylogger est installé ou autre

N'oubliez pas non plus la sécurité du réseau, votre tunnel chiffré valide-t-il qu'il n'est pas MITMd? Qu'en est-il des problèmes HTTPS, une CA compromise? Un autre scénario de style HEARTBLEED où tout le trafic vers le site a été compromis parce que le certificat en a été piraté? Aussi, si j'écris un keylogger maintenant, à moins qu'il y ait un grand nombre d'infections, vous ne pourrez pas nécessairement le détecter. Vous connectez-vous sur d'autres machines que d'autres ont utilisées? Laissez-vous d'autres personnes utiliser vos machines? Et les appareils mobiles? Mettez-vous régulièrement à jour votre ordinateur? Que faire si je vous regarde taper votre mot de passe dans un lieu public équipé de vidéosurveillance? Keylogger matériel? Attaque de méchante maid?

.. Je pense que tout cela est une grande hypothèse ...

y a-t-il un risque à réutiliser ce mot de passe pour plusieurs sites Web si cela ne peut jamais être craqué au cours de leur vie si une violation de données se produisait sur l'un des services qu'ils utilisent?

Récemment, il a été révélé alors que Twitter pouvait stocker les mots de passe en toute sécurité, leur fonctionnalité de journalisation le divulguait. Vous devez également exclure une autre faiblesse spécifique à la mise en œuvre dans toute la mise en œuvre du site.

Vous y faites allusion dans la préface à propos des sites non sécurisés, donc je suppose que vous supposez également que tous les sites sur lesquels vous utiliserez ce mot de passe que vous connaissez sécurisent également le mot de passe en toute sécurité. Pour la plupart des sites que j'utilise en ligne, comment vais-je le savoir ? Je ne le ferai pas et même s'ils disent qu'ils hachent les mots de passe en toute sécurité, il n'y a aucune garantie qu'ils le font.

Utilisez des mots de passe différents pour différents sites. Utilisez un gestionnaire de mots de passe, KeePass est plutôt bien :-).

Vous supposez qu'aucun des sites qu'ils visitent n'est hostile. Si je m'inscris sur un site et que je leur donne mon adresse e-mail et que j'utilise le même mot de passe pour ce site que je le fais pour mon adresse e-mail, ils peuvent se connecter à mon e-mail.

Quelque chose que Mark Zuckerberg avoue avoir fait quand démarrer le facebook.

Si une personne devait créer un mot de passe correctement aléatoire de longueur suffisante (par exemple 100+) d'entropie très suffisante qui est mélangé avec de nombreux types de symboles, de chiffres et de lettres; dans le cas où leur machine n'est pas compromise dans le sens où un keylogger est installé ou similaire, et que toutes leurs sessions de navigation sont effectuées via un tunnel crypté, y a-t-il un risque à réutiliser ce mot de passe pour plusieurs sites Web si cela ne peut jamais être craqué au cours de leur vie si une violation de données s'est produite sur l'un des services qu'ils utilisent?

Cela pose quelques problèmes. Tout d'abord, les mots de passe que vous suggérez sont bien trop longs. Il y a environ 2 ^ 6,6 caractères ASCII imprimables. Un mot de passe aléatoire uniforme de 20 caractères est donc suffisant pour une sécurité de 128 bits, et 39 caractères suffisent pour 256 bits. Des phrases de passe fortes pourraient éventuellement entrer dans le territoire de plus de 100 caractères, mais leur force n'a pas grand-chose à voir avec la quantité de symboles ou de lettres.

Le deuxième problème, et plus important, est que vous accordez une confiance inutile aux développeurs du site . Si aucun des sites n'a jamais de bogue permettant à un attaquant de récupérer le mot de passe, alors oui, il serait prudent de réutiliser le mot de passe. Le problème est que c'est un énorme "si". Il est très facile, même pour un site Web qui a conçu un bon système de stockage de mots de passe, de divulguer accidentellement vos mots de passe. Considérez cet incident Twitter très récent (du début du mois):

Aujourd'hui, Twitter a émis une alerte aux utilisateurs les invitant à changer leur mot de passe après la découverte que certains utilisateurs Les mots de passe avaient été enregistrés en texte brut dans un fichier journal accessible uniquement par les employés de Twitter.

[...] Mais à cause d'un bogue de codage, a expliqué Agrawal, "les mots de passe ont été écrits dans un journal interne avant de terminer le processus de hachage. Nous avons trouvé cette erreur nous-mêmes, supprimé les mots de passe et implémentons des plans pour éviter ce bogue. de se reproduire. "

C'est une erreur très facile à faire pour un programmeur; vous ajoutez simplement une ligne log (LogLevel.DEBUG, "loginRecord = {}", loginRecord) ou similaire dans votre programme et quelqu'un d'autre active par inadvertance la journalisation de débogage en production. Maintenant, multipliez cela par des milliers de programmeurs sur des milliers de jours sur des dizaines de sites Web, et les dés sont très contre vous. Ne réutilisez pas les mots de passe. Et utilisez un gestionnaire de mots de passe.

Modifier l'idée originale

Une modification de votre idée pourrait être assez sûre, cependant. Disons que vous générez 64 octets de données aléatoires, puis que vous les enregistrez dans un fichier. Vous choisissez ensuite un "Mot de passe principal" que vous ne dites jamais à personne, puis utilisez ce mot de passe, le fichier enregistré et le nom du site pour générer un mot de passe spécifique au site:

(echo super-secret-mot de passe; chat test-rand; echo amazon.com) | md5sum | sed 's /. * $ //' | xxd -r -p | base64

La ligne de commande ci-dessus produira toujours le mot de passe Tj02tXSPT + cQvN + 79QqtjA == à partir du fichier aléatoire particulier que j'ai créé, mais si je change amazon en google , il produira à la place oX9uOqM0 / wUaNzUlTMUcfg == .

Si je tape le mot de passe principal de manière incorrecte, j'obtiens quelque chose de complètement différent en sortie, mais tant que je le mets correctement , J'obtiens toujours la même sortie pour le même site, mais une sortie différente pour chaque site différent. Désormais, personne ne possède le "fichier clé" et le mot de passe principal (une sorte d'authentification à deux facteurs) nécessaires pour générer les mots de passe spécifiques au site. Si amazon est compromis, mon mot de passe google ne l'est pas. Les mots de passe contiennent chacun 128 bits de caractère aléatoire, ce qui devrait être suffisant pour presque tout.

La réutilisation du mot de passe est toujours une évaluation des risques. En termes pratiques, la réutilisation du mot de passe est un fait et la question est de savoir où utiliser quel ensemble.

Cependant, la vraie réponse à votre question est qu'il existe de nombreuses façons de compromettre un mot de passe et de forcer brutalement est en fait le moins probable. Il existe des renifleurs, des enregistreurs de frappe, des MitM, des serveurs compromis, diverses formes de XSS et d'autres attaques Web, le surf à l'épaule et probablement une douzaine d'autres moyens d'accéder à votre mot de passe, et pour beaucoup d'entre eux, la complexité ou la longueur du mot de passe ne fait aucune différence.

Un mot de passe peut être compromis de nombreuses manières. L'utilisation de mots de passe incassables, au mieux, ne fait rien pour atténuer le risque de compromission par d'autres moyens. En réalité, cela aggrave d'autres faiblesses.