S3 Ep95 : Fuite de Slack, assaut de Github et crypto post-quantique [Audio + Texte]

Cliquez et faites glisser sur les ondes sonores ci-dessous pour passer à n'importe quel point. Vous pouvez également écouter directement sur Soundcloud.

DOUG.  Fuites lâches, code GitHub coquin et cryptographie post-quantique.

Tout cela, et bien plus encore, sur le podcast Naked Security.

[MODÈME MUSICAL]

Bienvenue sur le podcast, tout le monde.

Je suis Doug Aamoth.

Avec moi, comme toujours, Paul Ducklin.

Paul, comment vas-tu aujourd'hui ?

---

CANARD.  Super duper, comme d'habitude, Doug !

---

DOUG.  Je suis super excité d'arriver à cette semaine Histoire de la technologie segment, parce que…

… tu étais là, mec !

Cette semaine, le 11 août…

---

CANARD.  Oh non!

Je pense que le sou vient de tomber…

---

DOUG.  Je n'ai même pas besoin de dire l'année !

11 août 2003 – le monde a remarqué le ver Blaster, affectant les systèmes Windows 2000 et Windows XP.

Blaster, également connu sous le nom de Lovesan et MsBlast, a exploité un débordement de mémoire tampon et est peut-être mieux connu pour le message, « Billy Gates, pourquoi rendez-vous cela possible ? Arrêtez de gagner de l'argent et corrigez votre logiciel.

Que s'est-il passé, Paul ?

---

CANARD.  Eh bien, c'était peut-être l'époque où nous prenions la sécurité très au sérieux.

Et, heureusement, ce genre de bogue serait beaucoup, beaucoup plus difficile à exploiter de nos jours : il s'agissait d'un débordement de tampon basé sur la pile.

Et si je me souviens bien, les versions serveur de Windows étaient déjà construites avec ce qu'on appelle protection de la pile.

En d'autres termes, si vous débordez la pile à l'intérieur d'une fonction, alors, avant que la fonction ne revienne et n'endommage la pile corrompue, elle détectera que quelque chose de mauvais s'est produit.

Ainsi, il doit arrêter le programme incriminé, mais le logiciel malveillant ne peut pas s'exécuter.

Mais cette protection n'était pas dans les versions clientes de Windows à l'époque.

Et si je me souviens bien, c'était l'un de ces premiers logiciels malveillants qui devaient deviner quelle version du système d'exploitation vous aviez.

tu es en 2000 ? Es-tu sur NT ? T'es sous XP ?

Et s'il se trompait, une partie importante du système se bloquerait et vous obtiendrez l'avertissement "Votre système est sur le point de s'arrêter".

---

DOUG.  Ha, je m'en souviens !

---

CANARD.  Donc, il y a eu ce dommage collatéral qui était, pour beaucoup de gens, le signe que vous vous faisiez marteler par des infections…

… qui pourrait provenir de l'extérieur, comme si vous n'étiez qu'un utilisateur à domicile et que vous n'aviez pas de routeur ou de pare-feu à la maison.

Mais si vous étiez à l'intérieur d'une entreprise, l'attaque la plus probable viendrait de quelqu'un d'autre à l'intérieur de l'entreprise, crachant des paquets sur votre réseau.

Donc, tout comme l'attaque CodeRed dont nous avons parlé, qui s'est déroulée quelques années auparavant, dans un podcast récent, c'était vraiment l'ampleur, le volume et la vitesse de cette chose qui posaient problème.

---

DOUG.  C'était il y a environ 20 ans.

Et si nous remontons le temps jusqu'à il y a cinq ans, c'est à ce moment-là Slack a commencé à fuir mots de passe hachés. [RIRE]

---

CANARD.  Oui, Slack, l'outil de collaboration populaire…

… il a une fonctionnalité où vous pouvez envoyer un lien d'invitation à d'autres personnes pour rejoindre votre espace de travail.

Et, vous imaginez : vous cliquez sur un bouton qui dit "Générer un lien", et cela va créer une sorte de paquet réseau qui contient probablement du JSON à l'intérieur.

Si vous avez déjà eu une invitation à une réunion Zoom, vous saurez qu'elle a une date et une heure, et la personne qui vous invite, et une URL que vous pouvez utiliser pour la réunion, et un mot de passe, et tout ça trucs - il y a beaucoup de données là-dedans.

Normalement, vous ne fouillez pas dans les données brutes pour voir ce qu'elles contiennent – ​​le client dit simplement : « Hé, voici une réunion, voici les détails. Voulez-vous Accepter / Peut-être / Refuser ? »

Il s'est avéré que lorsque vous avez fait cela avec Slack, comme vous le dites, pendant plus de cinq ans, cette invitation contenait des données superflues qui n'étaient pas strictement pertinentes pour l'invitation elle-même.

Donc, pas une URL, pas un nom, pas une date, pas une heure…

…mais le *hachage du mot de passe de l'utilisateur invitant* [RIRES]

---

DOUG.  Hmmmmm.

---

CANARD.  Je ne plaisante pas!

---

DOUG.  Ça sonne mal…

---

CANARD.  Oui, c'est vraiment le cas, n'est-ce pas ?

La mauvaise nouvelle est, comment diable cela est-il arrivé là-bas?

Et, une fois là-dedans, comment diable a-t-il pu échapper à l'attention pendant cinq ans et trois mois ?

En fait, si vous visitez l'article sur Naked Security et regardez le URL complète de l'article, vous remarquerez qu'il est écrit à la fin, blahblahblah-for-three-months.

Parce que, quand j'ai lu le rapport pour la première fois, mon esprit ne voulait pas le voir comme 2017 ! [RIRE]

C'était du 17 avril au 17 juillet, et il y avait donc beaucoup de "17" là-dedans.

Et mon esprit a effacé 2017 comme année de départ - je l'ai mal interprété comme "avril à juillet *de cette année*" [2022].

J'ai pensé, "Wow, *trois mois* et ils n'ont pas remarqué."

Et puis le premier commentaire sur l'article était, « Hum [TOUSSE]. C'était en fait le 17 avril *2017*.

Hou la la!

Mais quelqu'un l'a compris le 17 juillet [2022], et Slack, à leur crédit, l'a réparé le même jour.

Comme, "Oh, bon sang, à quoi pensions-nous ?!"

C'est donc la mauvaise nouvelle.

La bonne nouvelle est qu'au moins, il s'agissait de mots de passe *hachés*.

Et ils n'étaient pas seulement hachés, ils étaient *salés*, c'est-à-dire que vous mélangez des données aléatoires par utilisateur choisies de manière unique avec le mot de passe.

L'idée de ceci est double.

Premièrement, si deux personnes choisissent le même mot de passe, elles n'obtiennent pas le même hachage, vous ne pouvez donc pas faire d'inférences en parcourant la base de données de hachage.

Et deuxièmement, vous ne pouvez pas précalculer un dictionnaire de hachages connus pour les entrées connues, car vous devez créer un dictionnaire séparé pour chaque mot de passe * pour chaque sel *.

Ce n'est donc pas un exercice trivial de casser des mots de passe hachés.

Cela dit, l'idée est qu'ils ne sont pas censés être du domaine public.

Ils sont hachés et salés * au cas où * ils fuient, pas * pour qu'ils puissent * fuir.

Alors, œuf sur le visage de Slack !

Slack indique qu'environ un utilisateur sur 200, soit 0.5 %, a été affecté.

Mais si vous êtes un utilisateur de Slack, je suppose que s'ils n'ont pas réalisé qu'ils divulguaient des mots de passe hachés pendant cinq ans, ils n'ont peut-être pas non plus énuméré complètement la liste des personnes concernées.

Alors, allez quand même changer votre mot de passe… vous pourriez aussi bien.

---

DOUG.  OK, nous disons aussi : si vous n'utilisez pas de gestionnaire de mots de passe, envisagez d'en obtenir un ; et activez 2FA si vous le pouvez.

---

CANARD.  J'ai pensé que tu aimerais ça, Doug.

---

DOUG.  Oui!

Et puis, si vous êtes Slack ou une entreprise comme ça, choisissez un algorithme réputé de hachage et d'étirement du sel lors de la manipulation des mots de passe vous-même.

---

CANARD.  Oui.

Le gros problème dans la réponse de Slack, et la chose qui, à mon avis, manquait, c'est qu'ils ont juste dit : « Ne vous inquiétez pas, non seulement nous avons haché les mots de passe, mais nous les avons également salés.

Mon conseil est que si vous êtes pris dans une violation comme celle-ci, vous devriez être prêt à déclarer l'algorithme ou le processus que vous avez utilisé pour le salage et le hachage, et aussi idéalement ce qu'on appelle étirage, où vous ne hachez pas simplement le mot de passe salé une fois, mais peut-être le hachez-vous 100,000 XNUMX fois pour ralentir tout type d'attaque par dictionnaire ou par force brute.

Et si vous indiquez quel algorithme vous utilisez et avec quels paramètres.. par exemple, PBKDF2, bcrypt, scrypt, Argon2 - ce sont les algorithmes de mot de passe "salt-hash-stretch" les plus connus.

Si vous indiquez réellement quel algorithme vous utilisez, alors : [A] vous êtes plus ouvert, et [B] vous donnez aux victimes potentielles du problème une chance d'évaluer par elles-mêmes à quel point elles pensent que cela aurait pu être dangereux .

Et ce genre d'ouverture peut en fait beaucoup aider.

Slack n'a pas fait ça.

Ils ont juste dit: "Oh, ils étaient salés et hachés."

Mais ce que nous ne savons pas, c'est qu'ils ont mis deux octets de sel, puis les ont hachés une fois avec SHA-1…

… ou avaient-ils quelque chose d'un peu plus résistant au crack ?

---

DOUG.  Pour en revenir au sujet des mauvaises choses, nous remarquons une tendance qui se développe selon laquelle les gens sont injecter de mauvaises choses dans GitHub, juste pour voir ce qui se passe, exposant le risque…

… nous avons une autre de ces histoires.

---

CANARD.  Oui, quelqu'un qui est maintenant allé sur Twitter et a dit : « Ne vous inquiétez pas les gars, pas de mal. C'était juste pour la recherche. Je vais rédiger un rapport, me démarquer de Blue Alert.

Ils ont créé littéralement des milliers de faux projets GitHub, basés sur la copie de code légitime existant, en y insérant délibérément des commandes de logiciels malveillants, telles que "appeler à la maison pour plus d'instructions", et "interpréter le corps de la réponse comme un code de porte dérobée à exécuter", et bientôt.

Donc, des choses qui pourraient vraiment faire du mal si vous installiez l'un de ces packages.

Leur donner des noms légitimes…

… empruntant, apparemment, l'historique de validation d'un projet authentique afin que la chose ait l'air beaucoup plus légitime que ce à quoi vous pourriez vous attendre si elle s'affichait simplement avec, "Hé, téléchargez ce fichier. Tu sais que tu le veux!"

Vraiment?! Rechercher?? Nous ne le savions pas déjà ?!!?

Maintenant, vous pouvez argumenter, "Eh bien, Microsoft, qui possède GitHub, que font-ils pour rendre si facile pour les gens de télécharger ce genre de choses?"

Et il y a du vrai là-dedans.

Peut-être qu'ils pourraient faire un meilleur travail pour empêcher les logiciels malveillants d'entrer en premier lieu.

Mais c'est un peu exagéré de dire : « Oh, tout est de la faute de Microsoft.

C'est encore pire, à mon avis, de dire : « Oui, c'est de la vraie recherche ; c'est vraiment important; nous devons rappeler aux gens que cela pourrait arriver.

Eh bien, [A] nous le savons déjà, merci beaucoup, car beaucoup de gens l'ont déjà fait ; nous avons reçu le message haut et fort.

Et [B] ce *n'est pas* de la recherche.

Cela tente délibérément d'inciter les gens à télécharger du code qui donne à un attaquant potentiel le contrôle à distance, en échange de la possibilité de rédiger un rapport.

Pour moi, cela ressemble plus à une "grosse excuse" qu'à une motivation légitime pour la recherche.

Et donc ma recommandation est, si vous pensez que c'est *une* recherche, et si vous êtes déterminé à refaire quelque chose comme ça, *ne vous attendez pas à beaucoup de sympathie* si vous vous faites prendre.

---

DOUG.  Très bien - nous y reviendrons et les commentaires des lecteurs à la fin de l'émission, alors restez dans les parages.

Mais d'abord, parlons de feux de circulation, et ce qu'ils ont à voir avec la cybersécurité.

---

CANARD.  Ahhh, oui ! [RIRE]

Eh bien, il y a une chose appelée TLP, le Protocole des feux de circulation.

Et le TLP est ce que vous pourriez appeler un "protocole de recherche sur la cybersécurité humaine" qui vous aide à étiqueter les documents que vous envoyez à d'autres personnes, pour leur donner une idée de ce que vous espérez qu'ils feront (et, plus important encore, de ce que vous espérez qu'ils feront * pas*) faire avec les données.

En particulier, à quelle échelle sont-ils censés le redistribuer ?

Est-ce quelque chose de si important que vous pourriez le déclarer au monde ?

Ou est-ce potentiellement dangereux, ou cela inclut-il potentiellement des choses que nous ne voulons pas encore rendre publiques… alors gardez-le pour vous ?

Et ça a commencé par : TLP:RED, ce qui signifiait « Garde-le pour toi » ; TLP:AMBER, ce qui signifiait « Vous pouvez le faire circuler au sein de votre entreprise ou auprès de vos clients qui, selon vous, pourraient avoir un besoin urgent de le savoir » ; TLP:GREEN, ce qui signifiait "OK, vous pouvez laisser cela circuler largement au sein de la communauté de la cybersécurité".

Et TLP:WHITE, ce qui signifiait "Vous pouvez le dire à n'importe qui".

Très utile, très simple : ROUGE, AMBRE, VERT… une métaphore qui fonctionne globalement, sans se soucier de la différence entre "secret" et "confidentiel" et de la différence entre "confidentiel" et "classifié", tout ce truc compliqué qui a besoin de beaucoup de lois autour de lui.

Eh bien, le TLP vient de recevoir quelques modifications.

Donc, si vous êtes dans la recherche sur la cybersécurité, assurez-vous d'en être conscient.

TLP:WHITE a été remplacé par ce que je considère comme un bien meilleur terme en fait, parce que blanc a toutes ces connotations culturelles inutiles dont nous pouvons nous passer à l'ère moderne.

Alors, TLP:WHITE vient de devenir TLP:CLEAR, qui, à mon avis, est un bien meilleur mot car il dit : « Vous êtes prêt à utiliser ces données », et cette intention est énoncée, euh, très clairement. (Désolé, je n'ai pas pu résister au jeu de mot.)

Et il y a une couche supplémentaire (cela a donc un peu gâché la métaphore - c'est maintenant un feu tricolore *cinq* couleurs !).

Il y a un niveau spécial appelé TLP:AMBER+STRICT, et cela signifie : "Vous pouvez partager cela au sein de votre entreprise".

Donc, vous pourriez être invité à une réunion, peut-être travaillez-vous pour une entreprise de cybersécurité, et il est tout à fait clair que vous devrez le montrer aux programmeurs, peut-être à votre équipe informatique, peut-être à vos responsables de l'assurance qualité, afin que vous puissiez faire des recherches sur le problème ou s'occuper de le résoudre.

Mais TLP:AMBER+STRICT signifie que même si vous pouvez le diffuser au sein de votre organisation, *veuillez ne pas le dire à vos clients ou à vos clients*, ou même à des personnes extérieures à l'entreprise dont vous pensez qu'elles pourraient avoir besoin de savoir.

Gardez-le au sein de la communauté plus étroite pour commencer.

TLP:AMBER, comme avant, signifie "OK, si vous sentez que vous devez en parler à vos clients, vous pouvez."

Et cela peut être important, car parfois vous voudrez peut-être informer vos clients : « Hé, nous avons le correctif à venir. Vous devrez prendre certaines mesures de précaution avant que le correctif n'arrive. Mais parce que c'est un peu sensible, pouvons-nous vous demander de ne pas le dire au monde pour l'instant ? »

Parfois, dire au monde trop tôt fait plus le jeu des escrocs que celui des défenseurs.

Donc, si vous êtes un intervenant en cybersécurité, je vous suggère d'aller : https://www.first.org/tlp

---

DOUG.  Et tu peux en savoir plus à ce sujet sur notre site, nudesecurity.sophos.com.

Et si vous cherchez une autre lecture légère, oubliez la cryptographie quantique… nous passons à cryptographie post-quantique, Paul!

---

CANARD.  Oui, nous en avons déjà parlé plusieurs fois sur le podcast, n'est-ce pas ?

L'idée d'un ordinateur quantique, en supposant qu'un ordinateur suffisamment puissant et fiable puisse être construit, est que certains types d'algorithmes pourraient être accélérés par rapport à l'état de l'art actuel, soit à hauteur de la racine carrée… ou pire encore, le *logarithme* de l'ampleur du problème aujourd'hui.

Autrement dit, au lieu de prendre 2²⁵⁶ essaie de trouver un fichier avec un hachage particulier, vous pourrez peut-être le faire en juste ("juste" !) 2¹²⁸ essais, qui est la racine carrée.

Clairement beaucoup plus rapide.

Mais il existe toute une classe de problèmes impliquant la factorisation de produits de nombres premiers qui, selon la théorie, pourraient être résolus dans le * logarithme * du temps qu'ils prennent aujourd'hui, en gros.

Ainsi, au lieu de prendre, disons, 2¹²⁸ jours pour se fissurer [BIEN PLUS LONGTEMPS QUE L'ÂGE ACTUEL DE L'UNIVERS], cela pourrait ne prendre que 128 jours pour se fissurer.

Ou vous pouvez remplacer "jours" par "minutes", ou autre.

Et malheureusement, cet algorithme de temps logarithmique (appelé Algorithme de factorisation quantique de Shor)… qui pourrait s'appliquer, en théorie, à certaines des techniques cryptographiques actuelles, notamment celles utilisées pour la cryptographie à clé publique.

Et, juste au cas où ces dispositifs informatiques quantiques deviendraient réalisables dans les prochaines années, peut-être devrions-nous commencer à nous préparer dès maintenant à des algorithmes de chiffrement qui ne sont pas vulnérables à ces deux classes particulières d'attaques ?

En particulier celui du logarithme, car il accélère tellement les attaques potentielles que les clés cryptographiques que nous pensons actuellement, "Eh bien, personne ne le découvrira jamais", pourraient devenir révélables à un stade ultérieur.

Quoi qu'il en soit, le NIST, le Institut National des Standards et de la technologie aux États-Unis, organise depuis plusieurs années un concours pour essayer de standardiser des algorithmes publics, non brevetés et bien contrôlés qui résisteront à ces ordinateurs quantiques magiques, si jamais ils se présentent.

Et récemment, ils ont choisi quatre algorithmes qu'ils sont prêts à standardiser maintenant.

Ils ont des noms sympas, Doug, donc je dois les lire : CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONet SPHINCS+. [RIRE]

Ils ont donc des noms sympas, si rien d'autre.

Mais, en même temps, le NIST s'est dit : « Eh bien, ce ne sont que quatre algorithmes. Ce que nous allons faire, c'est que nous en choisirons quatre autres comme candidats secondaires potentiels, et nous verrons si l'un d'entre eux devrait également passer.

Il existe donc actuellement quatre algorithmes standardisés et quatre algorithmes qui pourraient être standardisés à l'avenir.

Ou il *y en avait* quatre le 5 juillet 2022, et l'un d'eux était SIKE, court pour encapsulation de clé d'isogénie supersingulière.

(Nous aurons besoin de plusieurs podcasts pour expliquer les isogénies supersingulières, donc nous ne nous embêterons pas. [RIRES])

Mais, malheureusement, celui-ci, qui s'accrochait là-dedans avec une chance d'être normalisé, il semble qu'il ait été irrémédiablement brisé, malgré au moins cinq ans d'avoir déjà été ouvert à l'examen public.

Donc, heureusement, juste avant qu'il ne soit ou ne puisse être standardisé, deux cryptographes belges ont compris : « Vous savez quoi ? Nous pensons que nous avons un moyen de contourner cela en utilisant des calculs qui prennent environ une heure, sur un processeur assez moyen, en utilisant un seul cœur.

---

DOUG.  Je suppose qu'il vaut mieux le découvrir maintenant qu'après l'avoir standardisé et l'avoir sorti dans la nature ?

---

CANARD.  En Effet!

Je suppose que s'il s'agissait de l'un des algorithmes déjà normalisés, ils auraient dû abroger la norme et en proposer une nouvelle ?

Il semble étrange que cela n'ait pas été remarqué pendant cinq ans.

Mais je suppose que c'est toute l'idée de l'examen public : vous ne savez jamais quand quelqu'un pourrait juste frapper la fissure qui est nécessaire, ou le petit coin qu'il peut utiliser pour s'introduire et prouver que l'algorithme n'est pas aussi fort qu'on le pensait à l'origine.

Un bon rappel que si vous avez * déjà * pensé à tricoter votre propre cryptographie…

---

DOUG.  [RIRES] Non !

---

CANARD.  ..bien que nous vous ayons dit sur le podcast Naked Security N fois, "Ne faites pas ça!"

Cela devrait être le rappel ultime que, même lorsque de vrais experts publient un algorithme soumis à l'examen du public dans une compétition mondiale pendant cinq ans, cela ne laisse pas nécessairement suffisamment de temps pour exposer des défauts qui s'avèrent assez mauvais.

Donc, ce n'est certainement pas bon pour ça SIKE algorithme.

Et qui sait, peut-être sera-t-il retiré ?

---

DOUG.  Nous garderons un œil là-dessus.

Et alors que le soleil se couche lentement sur notre émission de cette semaine, il est temps d'entendre l'un de nos lecteurs sur l'histoire de GitHub dont nous avons parlé plus tôt.

Voler écrit:

«Il y a de la craie et du fromage dans les commentaires, et je déteste le dire, mais je peux vraiment voir les deux côtés de l'argument. Est-ce dangereux, gênant, chronophage et consommateur de ressources ? Oui, Bien sur que c'est ça. Est-ce ce que feraient des types à l'esprit criminel ? Oui oui ça l'est. Est-ce un rappel à quiconque utilise GitHub, ou tout autre système de référentiel de code d'ailleurs, que voyager en toute sécurité sur Internet nécessite un degré sain de cynisme et de paranoïa ? Oui. En tant qu'administrateur système, une partie de moi veut applaudir l'exposition du risque à portée de main. En tant qu'administrateur système d'un groupe de développeurs, je dois maintenant m'assurer que tout le monde a récemment parcouru toutes les entrées à la recherche d'entrées douteuses.

---

CANARD.  Oui, merci, RobB, pour ce commentaire, car je suppose qu'il est important de voir les deux côtés de l'argument.

Il y avait des commentateurs qui disaient simplement : « Quel est le problème avec ça ? C'est bien!"

Une personne a dit, "Non, en fait, ce test de stylo est bon et utile. Soyez heureux que ceux-ci soient exposés maintenant au lieu de lever la tête laide d'un véritable attaquant.

Et ma réponse à cela est la suivante : "Eh bien, ceci * est * une attaque, en fait."

C'est juste que quelqu'un est sorti par la suite en disant « Oh, non, non. Pas de mal! Honnêtement, je n'étais pas méchant.

Je ne pense pas que vous soyez obligé d'acheter cette excuse !

Mais de toute façon, ce n'est pas un test d'intrusion.

Ma réponse a été de dire, très simplement : "Les testeurs d'intrusion responsables n'agissent jamais [A] après avoir reçu une autorisation explicite, et [B] dans les limites de comportement convenues explicitement à l'avance."

Vous ne faites pas que créer vos propres règles, et nous en avons déjà discuté.

Donc, comme l'a dit un autre commentateur, qui est, je pense, mon commentaire préféré… Ecurbe a dit, «Je pense que quelqu'un devrait marcher de maison en maison et briser les fenêtres pour montrer à quel point les serrures de porte sont vraiment inefficaces. C'est en retard. Quelqu'un saute dessus, s'il vous plaît.

Et puis, juste au cas où vous ne réaliseriez pas que c'était de la satire, les amis, dit-il, "Ne pas!"

---

CANARD.  J'ai l'idée que c'est un bon rappel, et j'ai l'idée que si vous êtes un utilisateur de GitHub, à la fois en tant que producteur et consommateur, il y a des choses que vous pouvez faire.

Nous les listons dans les commentaires et dans l'article.

Par exemple, mettez une signature numérique sur tous vos commits afin qu'il soit évident que les modifications viennent de vous, et qu'il existe une sorte de traçabilité.

Et ne vous contentez pas de consommer aveuglément des choses parce que vous avez fait une recherche et qu'il "semblait" que ce pourrait être le bon projet.

Oui, nous pouvons tous apprendre de cela, mais cela compte-t-il vraiment comme un enseignement, ou est-ce juste quelque chose que nous devrions apprendre de toute façon ?

Je pense que ce n'est *pas* enseigner.

Ce n'est simplement *pas d'un niveau suffisamment élevé* pour être considéré comme de la recherche.

---

DOUG.  Excellente discussion autour de cet article, et merci de l'avoir envoyé, Rob.

Si vous avez une histoire intéressante, un commentaire ou une question que vous aimeriez soumettre, nous serions ravis de le lire sur le podcast.

Vous pouvez envoyer un courriel tips@sophos.com; vous pouvez commenter n'importe lequel de nos articles; ou vous pouvez nous contacter sur les réseaux sociaux : @NakedSecurity.

C'est notre émission d'aujourd'hui – merci beaucoup pour votre écoute.

Pour Paul Ducklin, je suis Doug Aamoth vous rappelant, jusqu'à la prochaine fois, de…

---

TOUS LES DEUX.  Restez en sécurité!

[MODÈME MUSICAL]