La réutilisation des mots de passe représente un risque terrible pour les utilisateurs car en cas de violation de données, les mots de passe n'étant pas stockés de manière suffisamment sécurisée, cela signifie que, par défaut, tous les autres services pour lesquels ils utilisent ce mot de passe sont également compromis. En général, 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 (qui n'ont jamais été destinés à stocker des mots de passe en toute sécurité), ce qui permet aux attaquants de forcer les mots de passe en utilisant simplement le hachage brut du GPU Puissance.
Si une personne devait créer un mot de passe correctement aléatoire d'une longueur suffisante (par exemple 100+) d'entropie très suffisante qui est mélangée à de nombreux types de symboles, chiffres et lettres; dans le cas où leur machine n'est pas compromise dans le sens où un enregistreur de frappe est installé ou similaire, et toutes leurs sessions de navigation se font via un tunnel crypté, y a-t-il un risque à réutiliser ce mot de passe pour plusieurs sites Web s'il le peut - éventuellement ne jamais être piraté de son vivant si une violation de données s'est produite sur l'un des services qu'il utilise?
Vous n'avez pas besoin de forcer un hachage pour voler un mot de passe. Un site Web pourrait ê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 le faire, 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). En outre, il y a toujours le bon vieux surf sur l'é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.
Vous devez donc 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.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 utilisé par le développeur du site Web jusqu'à ce qu'ils utilisent tous un mot de passe sécurisé, il ne le fait pas 't aider autant qu'il en 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:
Parce que s'il n'y a pas de XKCD pertinent, il y en aura bientôt.
La réutilisation des mots de passe représente un risque terrible pour les utilisateurs car en cas de violation de données,
Seulement 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 protègent rien. Même compromettre le compte de messagerie derrière eux ne vous apporte rien d'autre que la possibilité de rendre mon nom de guerre plus stupide qu'il ne le semble déjà.
les mots de passe n'étant pas stockés de manière suffisamment sécurisée,
Le mot de passe n'est pas enregistré. 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 mot de passe doivent être considérés compromis ET si l'attaquant connaît votre autre adresse e-mail , tous ceux qui utilisent ce mot de passe doivent être considérés ...
L'identité (à ces fins) est ce que vous êtes (adresse e-mail) plus ce que vous savez (mot de passe).
Si je sais que vous êtes "[email protected]" sur somerandomforum.com et wellsfargo.com ET que vous utilisez le même mot de passe pour les trois, vous êtes arrosé.
Mais si vous utilisez "[email protected]" sur les forums Web et [email protected] pour votre usage "personnel" et "[email protected]" pour un usage professionnel, alors c'est extrêmement difficile pour un algorithmic attaquant pour les trier.
En général, 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 sais que vous le savez, et je suis horriblement 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 "crypte" pauvre et morte ou la plus récente sans interruption du bloc), il n'y a pas d'aller-retour fiable et fiable du hachage au mot de passe.
Vous NE POUVEZ PAS et ne passez pas de eaf4c33ae978d3f2852021214a061534 à "Fred est mort". Vous POUVEZ ê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 des mots de passe en toute sécurité), ce qui permet aux attaquants de forcer les mots de passe en utilisant simplement la puissance brute de hachage GPU.
Quelle perte de temps et d'électricité qui serait BEAUCOUP mieux de dépenser des pièces de {WHATEVER} $.
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 Rainbow précalculées sont BEAUCOUP plus rapides lorsque vous parcourez les cinq millions d'e-mails: nom: mot de passe que vous venez d'extraire de BigWebSiteInc, et vous obtiendrez BEAUCOUP plus de résultats BEAUCOUP plus rapidement.
Et oui, sachez que les GPU peuvent calculer cela très rapidement., Mais les recherches sont beaucoup plus rapides, et je vais vouloir casser BEAUCOUP de mots de passe, pas seulement le vôtre.
Si je veux VOS informations d'identification, j'ai d'autres moyens de les obtenir et si je les veux assez mal ... oui, ce n'est probablement pas un forum que Stack Exchange veut héberger. Il y a beaucoup d'aspects à la sécurité et la cryptographie ne protège que certains d'entre eux.
Si une personne devait créer un mot de passe correctement aléatoire d'une longueur suffisante (par exemple 100+) d'entropie très suffisante qui est mélangée à de nombreux types de
Histoire vraie. Il y a un peu plus de dix ans, j'étais dans les réserves 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 avez dû mettre votre carte d'identité militaire dans un lecteur de carte à puce et entrer votre "numéro d'identification".
À un moment donné, j'ai obtenu une nouvelle carte d'identité, ce qui a nécessité un nouveau code PIN. Je suis donc allé au point d'entrée de la broche et j'ai mis un numéro à 10 chiffres de l'IIRC dans le clavier, puis je l'ai remis. Il a dit que mon PIN correspondu et je suis parti.
Je suis retourné dans mon unité et j'ai essayé de me connecter. Échec.
Je suis donc retourné. Quelques fois. Nous étions confus. Ensuite, j'ai raccourci le PIN et cela a fonctionné.
Il y avait une limite de 8 ou 9 caractères sur le PIN (ou quoi que ce soit. C'était $ MY_NUM-2). Le PREMIER système d'entrée rejetait silencieusement les numéros supplémentaires. Le second ne l'était pas, menant à un décalage. (Ou l'inverse)
ISTR il y a des trucs dans le readme SAMBA sur la première version de la base de données de mots de passe de NT stockant le hachage en 2 parties parce que les vieux trucs LANMAN (??) ne faisaient que des mots de passe de 8 caractères. Je ne sais pas comment cela a fonctionné.
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 enregistreur de frappe est installé ou similaire, et toutes leurs sessions de navigation se font via un tunnel crypté, y a-t-il un risque à réutiliser ce mot de passe pour plusieurs sites web s'il ne peut jamais être piraté 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 deux premières strophes de quelques chansons bien mémorisées. Au moins l'un d'eux a une faute d'orthographe accidentelle qui est définitivement réparée dans ma brane.
Le fait est que si je regarde un ID: pw hash dans un magasin de mots de passe (fichier, base de données, peu importe), JE VEUX le plus facile à briser possible. Je ne veux pas du gars qui utilise une sorte de magasin de clés solide et qui a un mot de passe différent pour tous les autres sites, je veux juste les fruits bas. Ce sont les plus susceptibles de réutiliser les mots de passe.
Alors oui, cela rend votre mot de passe plus sûr, 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 en obtenir plus d'un Et tant qu'un site Web que vous utilisez continue de stocker les mots de passe dans un mauvais hachage, vous êtes vulnérable.
C'est pourquoi j'étais pédant. Nous ne faisons pas stocker 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 un 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 juste pour correspondre au hachage de "Fred est mort" et alors vous avez perdu.
C'est au-dessus de quelqu'un qui met une caméra où il peut vous regarder taper, exécuter une attaque MITM sur votre session SSL (qui représente environ la moitié des grandes sociétés avec lesquelles j'ai travaillé ces dernières années - elles le font sur leur serveur proxy faire DLP), piratage du site Web pour mettre du code supplémentaire dans leur page de connexion, ou l'un des douze autres hacks.
Ou tout simplement mettre un pistolet sur votre genou. Ou des méthodes plus macabres.
Utiliser les mots de passe jetables pour jeter les données, plusieurs "identités" en ligne et un stockage de clé suffisamment sécurisé pour les choses importantes est probablement la meilleure solution. 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 apparaît comme un commentaire.
Le hachage stocké réel est généralement le mot de passe + un hachage, il est donc IS 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 interagir avec ce site comme vous.
Cela ne concerne pas le problème de la "réutilisation des mots de passe", mais résout le problème des mots de passe super longs. C'est comme dans ... euh ... dans d'autres domaines de la vie. Une certaine quantité est bonne, plus c'est mieux, mais trop va causer des problèmes.
En ce qui concerne l'utilisation de hachages "non sécurisés", les entreprises ont tendance à se préoccuper le plus des poursuites, et accessoirement 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 tout cela, et toutes les personnes qu'il a approché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 légales, 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 ce qui a été livré 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 résumer, 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 jamais = dupliquer certains d'entre eux (mes comptes de messagerie personnels, professionnels et professionnels, mots de passe bancaires, etc.). Ne vaut pas le risque.
Généralement un site Web utilisera 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 clair?
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 longueur 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 en ce sens qu'un enregistreur de frappe est installé ou similaire, et que toutes leurs sessions de navigation se font via un tunnel chiffré,
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 mieux connaître ont foiré leur système de mots de passe récemment: GitHub et Twitter ont tous deux des mots de passe en texte clair enregistrés ou mis en cache en interne.
Il n'y a également aucun 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 deviez les retaper).
Vous pouvez trouver différentes solutions pour le hachage de mot de passe sur les sites Web: des fonctions de mémoire dure comme Argon2 ou Scrypt, des vulnérabilités matérielles personnalisées, 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 le stockage ou transmission de mots de passe en clair.
Une fois qu'un mot de passe est compromis, il peut apparaître dans des listes de mots de passe qui sont utilisées pour attaquer d'autres sites Web. Ainsi, 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 un stockage en texte brut 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 des mots de passe en texte brut, la force de votre mot de passe n'obtient rien.
Malheureusement, de nombreux sites Web stockent les mots de passe en clair et il n'est pas toujours évident de savoir si un site Web le fait ou non. Il n'est donc pas sûr de réutiliser un mot de passe très fort en supposant que le hachage ne sera pas forcé par la force, car il peut toujours être stocké (et violé) en texte clair.
TL; DR: La fissuration du mot de passe n'est pas la seule considération de sécurité lors de la réutilisation du mot 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 à l'exception de les mots de passe craquables, 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 un grand nombre de déclarations que la plupart des gens ne contrôleront pas:
leur machine n'est pas compromise dans le sens où un enregistreur de frappe est installé ou similaire
N'oubliez pas non plus la sécurité du réseau, votre tunnel chiffré confirme-t-il qu'il ne s'agit pas de MITMd? Qu'en est-il des problèmes HTTPS, une autorité de certification compromise? Un autre scénario de style HEARTBLEED où tout le trafic vers le site a été compromis parce que le certificat a été piraté? De plus, si j'ai écrit un enregistreur de frappe maintenant, à moins qu'il n'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 votre ordinateur à jour? Et si je vous regarde taper votre mot de passe dans un lieu public équipé de vidéosurveillance? Enregistreur de frappe matériel? Attaque malfaisante de bonne?
..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 s'il ne peut jamais être piraté de leur vivant si une violation de données s'est produite sur l'un des services qu'ils utilisent?
Récemment, il a été révélé que Twitter pouvait stocker les mots de passe en toute sécurité, mais leur fonctionnalité de journalisation le révélait. Vous devez également exclure une autre faiblesse spécifique à l'implémentation dans l'ensemble de l'implémentation du site.
Vous y faites allusion dans la préface sur les sites non sécurisés, donc je suppose que vous supposez également que tous les sites utiliseront ce mot de passe que vous connaissez également sécurisez le mot de passe en toute sécurité. Pour la plupart des sites que j'utilise en ligne, comment vais-je savoir cela? 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 fassent.
Utilisez des mots de passe différents pour différents sites. Utilisez un gestionnaire de mots de passe, KeePass est plutôt bon :-).
Si une personne devait créer un mot de passe correctement aléatoire d'une longueur suffisante (par exemple 100+) d'entropie très suffisante qui est mélangée à de nombreux types de symboles, chiffres et lettres; dans le cas où leur machine n'est pas compromise dans le sens où un enregistreur de frappe est installé ou similaire, et toutes leurs sessions de navigation se font via un tunnel crypté, y a-t-il un risque à réutiliser ce mot de passe pour plusieurs sites web s'il ne peut jamais être piraté au cours de leur vie si une violation de données s'est produite sur l'un des services qu'ils utilisent?
Il y a quelques problèmes avec ça. Tout d'abord, les mots de passe que vous proposez sont beaucoup trop longs. Il y a environ 2 ^ 6,6 caractères imprimables ASCII caractères. 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. 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 et plus gros problème est que vous mettez une confiance inutile sur les implémenteurs du site. Si aucun des sites jamais a un bug qui permet à un attaquant de récupérer le mot de passe, puis oui, il serait sûr de réutiliser le mot de passe. Le problème est que c'est un énorme "si". C'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 envoyé une alerte aux utilisateurs les invitant à changer leurs mots de passe après avoir découvert que les mots de passe de certains utilisateurs avaient été enregistrés en texte brut dans un fichier journal accessible uniquement aux employés de Twitter.
[...] Mais en raison 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 mettons en œuvre des plans pour empêcher 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 du 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 contre vous. Ne réutilisez pas les mots de passe. Et utilisez un gestionnaire de mots de passe.
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 lors du démarrage de Facebook.
La réutilisation du mot de passe est toujours une évaluation des risques. En termes pratiques, la réutilisation des mots 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 le forçage brut est en fait le moins probable. Des renifleurs, des enregistreurs de frappe, MitM, des serveurs compromis, diverses formes de XSS et d'autres attaques Web, la navigation sur l'épaule et probablement une douzaine d'autres façons d'accéder à votre mot de passe existent, et pour beaucoup d'entre eux, la complexité ou la longueur du mot de passe ne fait aucune différence.
Une modification de votre idée pourrait cependant être assez sûre. Disons que vous générez 64 octets aléatoires de données, puis enregistrez-les dans un fichier. Vous choisissez ensuite un "mot de passe principal" que vous ne dites à personne, puis vous 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-password; cat 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 pour google, cela produira oX9uOqM0/wUaNzUlTMUcfg==
au lieu.
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 n'a 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 à peu près n'importe quoi.
Il existe plusieurs façons de compromettre un mot de passe. L'utilisation de mots de passe non fissurables, au mieux, ne fait rien pour atténuer le risque de compromis par d'autres moyens. En réalité, cela aggrave d'autres faiblesses.