S3 Ep95: Slack leak, Githubin hyökkäys ja post-quantum crypto [ääni + teksti]

Napsauta ja vedä alla olevia ääniaaltoja hypätäksesi mihin tahansa kohtaan. Voit myös kuuntele suoraan Soundcloudissa.

DOUG.  Hitaat vuodot, tuhma GitHub-koodi ja post-quantum-salaus.

Kaikki tämä ja paljon muuta Naked Security -podcastissa.

[MUSIIKKIMODEEMI]

Tervetuloa podcastiin kaikki.

Olen Doug Aamoth.

Minun kanssani, kuten aina, on Paul Ducklin.

Paul, miten voit tänään?

---

ANKKA.  Super-duper, kuten tavallista, Doug!

---

DOUG.  Olen superinnoissani pääseessäni tälle viikolle Tekninen historia segmentti, koska…

…olit siellä, mies!

Tällä viikolla 11. elokuuta…

---

ANKKA.  Voi ei!

Luulen, että penni on juuri pudonnut...

---

DOUG.  Minun ei tarvitse edes sanoa vuotta!

11. elokuuta 2003 – maailma huomasi Blaster-madon, joka vaikutti Windows 2000- ja Windows XP -järjestelmiin.

Blaster, joka tunnetaan myös nimellä Lovesan ja MsBlast, käytti hyväkseen puskurin ylivuotoa ja tunnetaan ehkä parhaiten viestistään, "Billy Gates, miksi teet tämän mahdolliseksi? Lopeta rahan tekeminen ja korjaa ohjelmistosi."

Mitä tapahtui, Paul?

---

ANKKA.  No, se oli aikakausi ennen kuin otimme turvallisuuden niin vakavasti.

Ja onneksi tällainen bugi olisi nykyään paljon, paljon vaikeampi hyödyntää: se oli pinopohjainen puskurin ylivuoto.

Ja jos muistan oikein, Windowsin palvelinversioita rakennettiin jo ns pinon suojaus.

Toisin sanoen, jos ylität pinon funktion sisällä, se havaitsee, että jotain pahaa on tapahtunut, ennen kuin funktio palaa ja tekee vaurioita vioittuneelle pinolle.

Joten sen on suljettava loukkaava ohjelma, mutta haittaohjelma ei pääse toimimaan.

Mutta tämä suojaus ei ollut tuolloin Windowsin asiakasversioissa.

Ja muistaakseni se oli yksi niistä varhaisista haittaohjelmista, joiden piti arvata, mikä käyttöjärjestelmän versio sinulla oli.

Oletko 2000? Oletko NT:ssä? Onko sinulla XP?

Ja jos se menisi pieleen, tärkeä osa järjestelmää kaatuisi ja saat "Järjestelmäsi sammuu" -varoituksen.

---

DOUG.  Hah, muistan ne!

---

ANKKA.  Joten siellä oli se sivuvaurio, joka oli monille ihmisille merkki siitä, että olet joutunut infektioiden lyömään…

…joka voi olla ulkopuolelta, kuten jos olisit vain kotikäyttäjä eikä sinulla olisi kotona reititintä tai palomuuria.

Mutta jos olit yrityksen sisällä, todennäköisin hyökkäys tuli joltain muulta yrityksen sisällä, joka sylki paketteja verkkoosi.

Joten, aivan kuten puhuimme CodeRed-hyökkäyksestä, joka oli muutama vuosi ennen sitä, äskettäisessä podcastissa, ongelma oli todellakin tämän asian pelkkä laajuus, määrä ja nopeus.

---

DOUG.  No, se oli noin 20 vuotta sitten.

Ja jos käännämme kelloa taaksepäin viiden vuoden takaiseen, se on silloin Slack alkoi vuotaa tiivistetyt salasanat. [NAURU]

---

ANKKA.  Kyllä, Slack, suosittu yhteistyötyökalu…

… siinä on ominaisuus, jolla voit lähettää kutsulinkin muille ihmisille liittyä työtilaan.

Ja voit kuvitella: napsautat painiketta, jossa lukee "Luo linkki", ja se luo jonkinlaisen verkkopaketin, jossa todennäköisesti on JSON.

Jos olet joskus saanut Zoom-kokouskutsun, tiedät, että siinä on päivämäärä ja kellonaika, sinut kutsuva henkilö ja kokoukseen käytettävä URL-osoite, pääsykoodi ja kaikki muut. tavaraa – siinä on aika paljon dataa.

Normaalisti et kaivaudu raakatietoihin nähdäksesi, mitä siellä on – asiakas vain sanoo: "Hei, tässä on kokous, tässä on yksityiskohdat. Haluatko hyväksyä / ehkä / hylätä?"

Kävi ilmi, että kun teit tätä Slackin kanssa, kuten sanot, yli viiden vuoden ajan, tuohon kutsuun pakattiin ylimääräisiä tietoja, jotka eivät varsinaisesti liity itse kutsuun.

Joten, ei URL-osoite, ei nimi, ei päivämäärä, ei aika…

…mutta *kutsuvan käyttäjän salasanan hash* [NAurua]

---

DOUG.  Hmmmmm.

---

ANKKA.  En poista sinua!

---

DOUG.  Se kuulostaa pahalta…

---

ANKKA.  Kyllä, se todella tekee, eikö olekin?

Huono uutinen on, miten ihmeessä se pääsi sinne?

Ja kun se oli siellä, kuinka ihmeessä se vältti huomautuksen viisi vuotta ja kolme kuukautta?

Itse asiassa, jos käyt Naked Security -artikkelissa ja katsot täydellinen URL-osoite artikkelin lopussa huomaat, että blahblahblah-for-three-months.

Koska kun luin raportin ensimmäisen kerran, mieleni ei halunnut nähdä sitä 2017:nä! [NAURU]

Oli 17. huhtikuuta 17. heinäkuuta, joten siellä oli paljon "17":iä.

Ja mieleni peitti vuoden 2017 aloitusvuonna – luin sen väärin "huhtikuusta heinäkuuhun *tämän vuoden*" [2022].

Ajattelin: "Vau, *kolme kuukautta*, eivätkä he huomanneet."

Ja sitten ensimmäinen kommentti artikkeliin oli: "Ahem [yskä]. Se oli itse asiassa 17. huhtikuuta *2017*."

Wow!

Mutta joku keksi sen 17. heinäkuuta [2022], ja heidän ansiokseensa Slack korjasi sen samana päivänä.

Kuten: "Voi kulta, mitä me ajattelimme?!"

Joten se on huono uutinen.

Hyvä uutinen on, että ainakin se oli *tiivistettyjä* salasanoja.

Ja niitä ei vain hajautettu, vaan ne *suolattiin*, jolloin sekoitat yksilöllisesti valittuja, käyttäjäkohtaisia ​​satunnaisia ​​tietoja salasanan kanssa.

Ajatus tästä on kaksijakoinen.

Yksi, jos kaksi ihmistä valitsee saman salasanan, he eivät saa samaa tiivistettä, joten et voi tehdä johtopäätöksiä hajautustietokannasta.

Ja toiseksi, et voi etukäteen laskea sanakirjaa tunnetuista tiivisteistä tunnetuille syötteille, koska sinun on luotava erillinen sanakirja jokaiselle salasanalle *jokaiselle suolalle*.

Hajautettujen salasanojen murtaminen ei siis ole triviaali harjoitus.

Tämän sanottuani koko ajatus on, että niiden ei pitäisi olla julkisia asiakirjoja.

Ne on tiivistetty ja suolattu * siltä varalta, että ne vuotavat, ei * jotta ne voisivat* vuotaa.

Joten muna Slackin kasvoille!

Slack kertoo, että noin yksi 200 käyttäjästä eli 0.5 prosenttia kärsi.

Mutta jos olet Slackin käyttäjä, olettaisin, että jos he eivät tajunneet vuotaneensa hajautettuja salasanoja viiden vuoden ajan, he eivät ehkä myöskään täysin luetelleet luetteloa henkilöistä, joita tämä koskee.

Joten mene ja vaihda salasanasi joka tapauksessa… voit yhtä hyvin.

---

DOUG.  OK, sanomme myös: jos et käytä salasananhallintaohjelmaa, harkitse sellaisen hankkimista; ja ota 2FA käyttöön, jos voit.

---

ANKKA.  Luulin sinun pitävän siitä, Doug.

---

DOUG.  Kyllä vain!

Ja sitten, jos olet Slack tai pidät siitä, valitse a hyvämaineinen suola-hash-and-stretch-algoritmi käsitellessäsi salasanoja itse.

---

ANKKA.  Kyllä.

Suuri asia Slackin vastauksessa ja se, mikä mielestäni puuttui, on se, että he vain sanoivat: "Älä huoli, me tiivistimme salasanoja, mutta myös suolasimme ne."

Neuvoni on, että jos jäät kiinni tällaisesta rikkomuksesta, sinun pitäisi olla valmis ilmoittamaan suolaamiseen ja hajauttamiseen käyttämäsi algoritmi tai prosessi, ja mieluiten myös ns. venyttely, jossa et vain tiivistä suolattua salasanaa kerran, vaan ehkä tiivistät sen 100,000 XNUMX kertaa hidastaaksesi kaikenlaista sanakirjaa tai raa'an voiman hyökkäyksiä.

Ja jos kerrot mitä algoritmia käytät ja millä parametreilla... esim. PBKDF2, bcrypt, scrypt, Argon2 - Nämä ovat tunnetuimpia salasanojen "salt-hash-stretch" -algoritmeja.

Jos todella kerrot, mitä algoritmia käytät, niin: [A] olet avoimempi ja [B] annat mahdollisille ongelman uhreille mahdollisuuden arvioida itse, kuinka vaarallista tämä on heidän mielestään voinut olla. .

Ja tällainen avoimuus voi todella auttaa paljon.

Slack ei tehnyt niin.

He vain sanoivat: "Voi, ne oli suolattu ja hajautettu."

Mutta emme tiedä, laittoivatko he kaksi tavua suolaa ja tiivistivat ne sitten kerran SHA-1:llä…

…vai oliko niissä jotain hieman kestävämpää murtumista vastaan?

---

DOUG.  Pidämme kiinni pahoista asioista, ja huomaamme kehittyvän trendin, jossa ihmiset ovat ruiskuttamalla huonoja asioita GitHubiin, vain nähdäkseni mitä tapahtuu, paljastaen riskin…

…meillä on toinen näistä tarinoista.

---

ANKKA.  Kyllä, joku, joka on nyt väitetysti ilmestynyt Twitteriin ja sanonut: "Älkää huoliko, ei vahinkoa ole tapahtunut. Se oli vain tutkimusta varten. Aion kirjoittaa raportin, erotu Blue Alertista."

He loivat kirjaimellisesti tuhansia vääriä GitHub-projekteja, jotka perustuivat olemassa olevan laillisen koodin kopioimiseen, siihen tarkoituksellisesti lisättyjen haittaohjelmien komentoihin, kuten "soita kotiin saadaksesi lisäohjeita" ja "tulkivat vastauksen tekstin suoritettavaksi takaovikoodiksi" ja pian.

Joten asioita, jotka voivat todella vahingoittaa, jos asennat jonkin näistä paketeista.

Anna niille laillisen näköisiä nimiä…

…lainataan ilmeisesti aidon projektin sitoutumishistoriaa, jotta asia näytti paljon laillisemmalta kuin muuten voisi odottaa, jos se vain ilmestyisi sanomalla: "Hei, lataa tämä tiedosto. Tiedät että haluat!"

Todella?! Tutkimus?? Emmekö tienneet tätä jo?!!?

Nyt voit väittää: "No, Microsoft, joka omistaa GitHubin, mitä he tekevät, jotta ihmisten on niin helppoa ladata tällaista sisältöä?"

Ja siinä on jonkin verran totuutta.

Ehkä he voisivat tehdä parempaa työtä pitääkseen haittaohjelmat poissa.

Mutta se on hieman ylivoimaista sanoa: "Voi, kaikki on Microsoftin syytä."

Minusta on vielä pahempaa sanoa: "Kyllä, tämä on aitoa tutkimusta; tämä on todella tärkeää; Meidän on muistutettava ihmisiä, että tämä voi tapahtua."

No, [A] me jo tiedämme sen, kiitos paljon, koska monet ihmiset ovat tehneet tämän aiemmin; saimme viestin äänekkäästi ja selkeästi.

Ja [B] tämä *ei ole* tutkimusta.

Tällä pyritään tietoisesti huijaamaan ihmisiä lataamaan koodia, joka antaa mahdolliselle hyökkääjälle kauko-ohjaimen vastineeksi mahdollisuudesta kirjoittaa raportti.

Se kuulostaa minusta enemmän "isolta tekosyyltä" kuin oikeutetulta motivaattorilta tutkimukseen.

Suositukseni on, että jos uskot tämän *on* tutkimusta ja jos olet päättänyt tehdä jotain tällaista uudestaan, *älä odota suurta myötätuntoa*, jos jäät kiinni.

---

DOUG.  Selvä – palaamme tähän ja lukijakommentteihin esityksen lopussa, joten pysy paikallasi.

Mutta ensin puhutaan liikennevalotja mitä tekemistä niillä on kyberturvallisuuden kanssa.

---

ANKKA.  Ahhh, kyllä! [NAURAA]

No, on olemassa asia nimeltä TLP Liikennevaloprotokolla.

Ja TLP on se, mitä voisi kutsua "ihmisen kyberturvallisuustutkimusprotokollaksi", joka auttaa sinua merkitsemään asiakirjoja, jotka lähetät muille ihmisille, antaakseen heille vihjeen siitä, mitä toivot heidän tekevän (ja mikä tärkeintä, mitä toivot heidän tekevän * ei*) tehdä datan kanssa.

Erityisesti kuinka laajasti heidän on tarkoitus jakaa se uudelleen?

Onko tämä niin tärkeä asia, että voit julistaa sen maailmalle?

Vai onko tämä mahdollisesti vaarallista, vai sisältääkö se mahdollisesti asioita, joita emme halua vielä julkaista… joten pidä se omana tietonasi?

Ja se alkoi: TLP:RED, joka tarkoitti "Pidä se itselläsi"; TLP:AMBER, mikä tarkoitti "Voit jakaa sen oman yrityksen sisällä tai asiakkaillesi, joiden arvelet tarvitsevan tämän kiireellisesti tietävän"; TLP:GREEN, mikä tarkoitti "OK, voit antaa tämän levitä laajasti kyberturvallisuusyhteisössä."

Ja TLP:WHITE, mikä tarkoitti: "Voit kertoa kenelle tahansa."

Erittäin hyödyllinen, hyvin yksinkertainen: PUNAINEN, KELTAINEN, VIHREÄ… metafora, joka toimii maailmanlaajuisesti ilman huolta siitä, mitä eroa on "salaisella" ja "luottamuksellisella" ja mitä eroa on "luottamuksellisella" ja "luokitellulla", kaikki se monimutkainen asia, joka vaatii paljon lakeja ympärilleen.

No, TLP sai juuri joitain muutoksia.

Joten jos olet kiinnostunut kyberturvallisuustutkimuksesta, varmista, että olet tietoinen niistä.

TLP:WHITE on muutettu mielestäni paljon paremmaksi termiksi, koska valkoinen sillä on kaikki nämä tarpeettomat kulttuuriset sävyt, joita ilman voimme tehdä nykyaikana.

Niin, TLP:WHITE on juuri tullut TLP:CLEAR, joka on mielestäni paljon parempi sana, koska se sanoo: "Olet selvää, että käytät näitä tietoja", ja tämä tarkoitus on ilmaistu, heh, hyvin selvästi. (Anteeksi, en voinut vastustaa sanapeliä.)

Ja siellä on ylimääräinen kerros (joten se on hieman pilannut metaforaa - se on nyt *viiden*-värinen liikennevalo!).

Siellä on erityinen taso nimeltä TLP:AMBER+STRICT, ja se tarkoittaa: "Voit jakaa tämän yrityksesi sisällä."

Joten sinut saatetaan kutsua kokoukseen, ehkä työskentelet kyberturvayrityksessä, ja on aivan selvää, että sinun on näytettävä tämä ohjelmoijille, ehkä IT-tiimillesi, ehkä laadunvarmistushenkilöillesi, jotta voit tehdä tutkimusta ongelman tai korjaa se.

Mutta TLP:AMBER+STRICT tarkoittaa, että vaikka voit kierrättää sitä organisaatiosi sisällä, *älä kerro asiakkaillesi* tai edes yrityksen ulkopuolisille ihmisille, joiden uskot olevan tarpeen tietää.

Pidä se aluksi tiukemmassa yhteisössä.

TLP:AMBER, kuten ennenkin, tarkoittaa "OK, jos sinusta tuntuu, että sinun on kerrottava asiakkaillesi, voit."

Ja se voi olla tärkeää, koska joskus saatat haluta kertoa asiakkaillesi: "Hei, meillä on korjaus tulossa. Sinun on ryhdyttävä varotoimiin, ennen kuin korjaus saapuu. Mutta koska se on jotenkin herkkää, saammeko pyytää, ettet kerro maailmalle vielä?"

Joskus liian aikaisin kertominen maailmalle on itse asiassa enemmän roistojen kuin puolustajien käsissä.

Joten jos olet kyberturvallisuusvastaava, suosittelen, että menet: https://www.first.org/tlp

---

DOUG.  Ja sinä voit lue lisää siitä sivustollamme, nakedsecurity.sophos.com.

Ja jos etsit muuta kevyttä luettavaa, unohda kvanttisalaus… siirrymme eteenpäin postkvanttinen salaus, Paul!

---

ANKKA.  Kyllä, olemme puhuneet tästä muutaman kerran aiemmin podcastissa, eikö niin?

Ajatus kvanttitietokoneesta, olettaen että riittävän tehokas ja luotettava voitaisiin rakentaa, on se, että tietyntyyppisiä algoritmeja voitaisiin nopeuttaa nykyaikaisen tekniikan tasoon, joko neliöjuuren säveleen… tai vielä pahempaa, *logaritmi* ongelman laajuudesta tänään.

Toisin sanoen, sen sijaan, että otat 2²⁵⁶ yrittää löytää tiedoston tietyllä hashilla, saatat pystyä tekemään sen vain ("vain"!) 2¹²⁸ yrittää, mikä on neliöjuuri.

Selvästi paljon nopeampi.

Mutta on olemassa joukko ongelmia, jotka liittyvät alkulukujen tulojen tekijöihin, jotka teorian mukaan voidaan murtaa nykyisen ajan *logaritmissa*, löyhästi puhuen.

Joten sen sijaan, että otat vaikkapa 2¹²⁸ päivän murtamiseen [PALJON PIDEMMÄN KUIN NYKYISEN KAIKKEUKSEN IKÄ], sen halkeaminen voi kestää vain 128 päivää.

Tai voit korvata sanat "päivät" sanalla "minuutit" tai mitä tahansa.

Ja valitettavasti tuo logaritminen aikaalgoritmi (ns Shorin kvanttifaktorointialgoritmi)… jota voitaisiin teoriassa soveltaa joihinkin tämän päivän salaustekniikoihin, erityisesti niihin, joita käytetään julkisen avaimen salaukseen.

Ja jos nämä kvanttilaskentalaitteet tulevat käyttökelpoisiksi muutaman seuraavan vuoden aikana, meidän pitäisi ehkä alkaa valmistautua nyt salausalgoritmeihin, jotka eivät ole haavoittuvia näille kahdelle tietylle hyökkäykselle?

Erityisesti logaritmi, koska se nopeuttaa mahdollisia hyökkäyksiä niin paljon, että salausavaimet, joita tällä hetkellä ajattelemme "No, kukaan ei tule koskaan ymmärtämään sitä", saattavat tulla paljastetuiksi jossain myöhemmässä vaiheessa.

Joka tapauksessa, NIST, Kansallinen standardointi- ja teknologiainstituutti Yhdysvalloissa, on usean vuoden ajan järjestänyt kilpailua yrittääkseen standardoida joitain julkisia, patentoimattomia, hyvin tutkittuja algoritmeja, jotka kestävät näitä maagisia kvanttitietokoneita, jos niitä koskaan ilmaantuu.

Ja äskettäin he valitsivat neljä algoritmia, jotka he ovat valmiita standardoimaan nyt.

Heillä on hienot nimet, Doug, joten minun on luettava ne: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONja SPHINCS+. [NAURU]

Joten heillä on hienot nimet, jos ei muuta.

Mutta samaan aikaan NIST ajatteli: "No, se on vain neljä algoritmia. Valitsemme neljä muuta mahdolliseksi toissijaiseksi ehdokkaaksi, ja katsomme, menestyykö joku heistäkin."

Joten nyt on neljä standardoitua algoritmia ja neljä algoritmia, jotka saattavat standardoitua tulevaisuudessa.

Tai * oli* neljä 5. heinäkuuta 2022, ja yksi heistä oli SIKE, lyhenne jstk supersingulaarinen isogeniaavaimen kapselointi.

(Tarvitsemme useita podcasteja supersingulaaristen isogeenien selittämiseen, joten emme vaivaudu. [NAurua])

Mutta valitettavasti tämä, joka roikkui siellä taistelevana mahdollisuutena standardoida, näyttää siltä, ​​että se on peruuttamattomasti rikki, vaikka se on ollut jo vähintään viisi vuotta avoinna julkisen tarkastelun alla.

Joten onneksi juuri ennen kuin se standardisoitiin tai voitiin saada, kaksi belgialaista kryptografia keksi: "Tiedätkö mitä? Uskomme, että voimme kiertää tämän käyttämällä laskelmia, jotka kestävät noin tunnin, melko keskimääräisellä prosessorilla, käyttämällä vain yhtä ydintä.

---

DOUG.  Luulen, että on parempi selvittää se nyt kuin standardoinnin ja sen saamisen jälkeen luonnossa?

---

ANKKA.  Todellakin!

Jos se olisi ollut yksi jo standardisoiduista algoritmeista, heidän olisi pitänyt kumota standardi ja keksiä uusi?

Tuntuu oudolta, että tätä ei huomattu viiteen vuoteen.

Mutta luulen, että se on koko julkisen tarkastelun idea: koskaan ei tiedä, milloin joku saattaa vain osua tarvittavaan halkeamaan tai pieneen kiilaan, jolla he voivat murtautua sisään ja todistaa, että algoritmi ei ole niin vahva kuin alun perin luultiin.

Hyvä muistutus siitä, että jos *koskaan* ajattelit neuloa oman kryptografian...

---

DOUG.  [NAURA] En ole!

---

ANKKA.  ..huolimatta siitä, että olemme kertoneet sinulle Naked Security podcastissa N kertaa: "Älä tee sitä!"

Tämän pitäisi olla lopullinen muistutus siitä, että vaikka todelliset asiantuntijat esittäisivät algoritmin, joka on julkisen valvonnan alainen maailmanlaajuisessa kilpailussa viiden vuoden ajan, tämä ei silti välttämättä tarjoa tarpeeksi aikaa paljastaa vikoja, jotka osoittautuvat melko huonoiksi.

Joten, se ei todellakaan näytä hyvältä tälle SIKE algoritmi.

Ja kuka tietää, ehkä se vedetään pois?

---

DOUG.  Pidämme sitä silmällä.

Ja kun aurinko laskee hitaasti tämän viikon ohjelmassamme, on aika kuulla yhdeltä lukijamme GitHub-tarinasta, josta keskustelimme aiemmin.

Ryöstää kirjoittaa:

"Kommenteissa on liitua ja juustoa, ja inhoan sanoa sitä, mutta näen aidosti väitteen molemmat puolet. Onko se vaarallista, hankalaa, aikaa vievää ja resursseja vievää? Kyllä, tietysti on. Tekevätkö sen rikollismieliset tyypit? Kyllä, kyllä, se on. Onko se muistutus kaikille, jotka käyttävät GitHubia tai jotain muuta koodivarastojärjestelmää, että turvallinen Internetissä matkustaminen vaatii terveellistä kyynisyyttä ja vainoharhaisuutta? Joo. Järjestelmänvalvojana osa minusta haluaa kiittää käsillä olevan riskin paljastamista. Useiden kehittäjien järjestelmänvalvojana minun on nyt varmistettava, että kaikki ovat viime aikoina etsineet kyseenalaisia ​​merkintöjä."

---

ANKKA.  Kyllä, kiitos, RobB, tästä kommentista, koska mielestäni on tärkeää nähdä väitteen molemmat puolet.

Jotkut kommentoijat sanoivat vain: "Mikä ihme tässä on ongelmana? Tämä on suurenmoista!"

Yksi henkilö sanoi, "Ei, itse asiassa tämä kynätestaus on hyvä ja hyödyllinen. Ole iloinen, että nämä paljastetaan nyt sen sijaan, että nostaisit rumaa päätään todellisesta hyökkääjästä."

Ja vastaukseni siihen on: "No, tämä *on* itse asiassa hyökkäys."

Se on vain, että joku on nyt tullut ulos jälkeenpäin sanoen "Voi, ei, ei. Ei mitään vahinkoa! Rehellisesti sanottuna en ollut tuhma."

En usko, että sinun on pakko ostaa sitä tekosyytä!

Mutta joka tapauksessa, tämä ei ole läpäisytestaus.

Vastaukseni oli sanoa hyvin yksinkertaisesti: "Vastuulliset läpäisytestaajat toimivat aina vain [A] saatuaan nimenomaisen luvan ja [B] käyttäytymisrajoissa, joista on erikseen sovittu etukäteen."

Et vain luo omia sääntöjäsi, ja olemme keskustelleet tästä aiemmin.

Joten, kuten toinen kommentoija sanoi, mikä on mielestäni suosikkikommenttini… Ecurb sanoi, ”Mielestäni jonkun pitäisi kävellä talosta taloon ja murskata ikkunat näyttääkseen kuinka tehottomia ovenlukot todella ovat. Tämä on erääntynyt. Hyppää joku tähän, kiitos."

Ja sitten, jos ette ymmärtäneet, että se oli satiiria, ihmiset, hän sanoo: "Ei!"

---

ANKKA.  Ymmärrän, että se on hyvä muistutus, ja ymmärrän, että jos olet GitHubin käyttäjä sekä tuottajana että kuluttajana, voit tehdä asioita.

Luettelemme ne kommenteissa ja artikkelissa.

Esimerkiksi, laita digitaalinen allekirjoitus kaikkiin sitoumuksiisi, jotta on selvää, että muutokset ovat peräisin sinusta, ja jäljitettävyys on jonkinlainen.

Äläkä vain sokeasti kuluta tavaraa, koska teit haun ja "näytti" siltä, ​​että se saattaa olla oikea projekti.

Kyllä, me kaikki voimme oppia tästä, mutta lasketaanko tämä meille opetukseksi vai onko se vain jotain, joka meidän pitäisi kuitenkin oppia?

Mielestäni tämä *ei* ole opetusta.

Se vain *ei ole tarpeeksi korkeatasoinen*, jotta sitä voidaan pitää tutkimuksena.

---

DOUG.  Loistava keskustelu tämän artikkelin ympärillä, ja kiitos, että lähetit sen, Rob.

Jos sinulla on mielenkiintoinen tarina, kommentti tai kysymys, jonka haluat lähettää, luemme sen mielellämme podcastista.

Voit lähettää sähköpostia tips@sophos.com; voit kommentoida mitä tahansa artikkeleistamme; tai voit lyödä meitä sosiaalisessa mediassa: @NakedSecurity.

Se on tämän päivän ohjelmamme – kiitos paljon kuuntelusta.

Paul Ducklinille olen Doug Aamoth, joka muistuttaa sinua seuraavaan kertaan asti…

---

Molemmat.  Pysy turvassa!

[MUSIIKKIMODEEMI]