S3 Ep95: Slack leak, Github támadás és kvantum utáni kriptográfia [Hang + szöveg]

Kattintson és húzza az alábbi hanghullámokat, hogy bármelyik pontra ugorjon. Te is hallgatni közvetlenül a Soundcloudon.

DOUG.  Laza szivárgások, szemtelen GitHub-kód és kvantum utáni kriptográfia.

Mindez, és még sok más, a Naked Security podcastban.

[ZENEI MODEM]

Üdvözlünk mindenkit a podcastban.

Doug Aamoth vagyok.

Velem, mint mindig, Paul Ducklin.

Paul, hogy vagy ma?

---

KACSA.  Szuper-duper, mint általában, Doug!

---

DOUG.  Nagyon izgatott vagyok, hogy elérhetem ezt a hetet Tech History szegmens, mert…

…ott voltál, haver!

Ezen a héten, augusztus 11-én…

---

KACSA.  Óh ne!

Szerintem most leesett a fillér…

---

DOUG.  Még az évet sem kell mondanom!

11. augusztus 2003. – a világ felfigyelt a Blaster férgére, amely a Windows 2000 és a Windows XP rendszereket érintette.

Blaster, más néven Lovesan és MsBlast, kihasználta a puffer túlcsordulást, és talán leginkább az üzenetről ismert, „Billy Gates, miért tetted ezt lehetővé? Ne keressen pénzt, és javítsa ki a szoftverét."

Mi történt, Paul?

---

KACSA.  Nos, ez a korszak volt, talán olyan komolyan vettük a biztonságot.

És szerencsére ezt a fajta hibát manapság sokkal-sokkal nehezebb lenne kihasználni: verem alapú puffertúlcsordulás volt.

És ha jól emlékszem, a Windows szerververziói már ún veremvédelem.

Más szóval, ha túlcsordul a verem egy függvényen belül, akkor mielőtt a függvény visszatérne, és kárt okozna a sérült veremmel, észleli, hogy valami rossz történt.

Tehát le kell állítania a jogsértő programot, de a rosszindulatú program nem indul el.

De ez a védelem akkoriban nem volt a Windows kliens verzióiban.

És ahogy emlékszem, egyike volt azoknak a korai rosszindulatú programoknak, amelyeknek ki kellett találniuk, hogy az operációs rendszer melyik verziója van.

2000-en vagy? NT-n vagy? XP-n vagy?

És ha rosszul csinálja, akkor a rendszer egy fontos része összeomlik, és „A rendszer hamarosan leáll” figyelmeztetést kap.

---

DOUG.  Ha, ezekre emlékszem!

---

KACSA.  Tehát volt az a járulékos kár, amely sok ember számára annak a jele volt, hogy fertőzések csaptak le…

…ami lehet kívülről, mintha csak otthoni felhasználó lennél, és nem lenne otthon router vagy tűzfal.

De ha egy vállalaton belül tartózkodik, a legvalószínűbb támadás a vállalaton belüli valakitől származott, és csomagokat okádott ki a hálózatán.

Tehát, nagyon hasonlóan a CodeRed támadáshoz, amiről beszéltünk, és ami néhány évvel azelőtt történt, egy nemrégiben megjelent podcastban, valójában ennek a dolognak a puszta mérete, mennyisége és sebessége volt a probléma.

---

DOUG.  Na jó, ez kb 20 éve volt.

És ha visszatekerjük az órát öt évvel ezelőttre, akkor az az idő Slack szivárogni kezdett kivonatolt jelszavak. [NEVETÉS]

---

KACSA.  Igen, a Slack, a népszerű együttműködési eszköz…

…van egy olyan funkciója, amellyel meghívó linket küldhet másoknak, hogy csatlakozzanak a munkaterületéhez.

És képzelje el: rákattint egy „Létrehoz egy hivatkozást” feliratú gombra, és az létrehoz valamiféle hálózati csomagot, amelyben valószínűleg van valami JSON.

Ha valaha is kapott Zoom értekezlet-meghívót, akkor tudni fogja, hogy van dátuma és időpontja, és a meghívó személye, valamint egy URL-címe, amelyet az értekezlethez használhat, és egy jelszó, és minden. cucc – elég sok adat van benne.

Általában nem kell beleásni a nyers adatokba, hogy megnézze, mi van benne – az ügyfél csak annyit mond: „Hé, itt egy találkozó, itt vannak a részletek. El akarja fogadni / Talán / Elutasítani?

Kiderült, hogy amikor ezt a Slack-kel csináltad, mint mondod, több mint öt éven keresztül, a meghívóban olyan idegen adatok voltak csomagolva, amelyek nem feltétlenül relevánsak magával a meghívóval.

Tehát nem URL, nem név, nem dátum, nem idő…

…de a *meghívó felhasználó jelszava hash* [NEVETÉS]

---

DOUG.  Hááát.

---

KACSA.  Nem viccelek!

---

DOUG.  Ez rosszul hangzik…

---

KACSA.  Igen, tényleg így van, nem?

A rossz hír az, hogy a fenébe került ez oda?

És ha egyszer bent volt, hogyan a fenébe kerülte el a figyelmét öt éven és három hónapon keresztül?

Valójában, ha felkeresi a Naked Security című cikket, és megnézi a teljes URL a cikk végén észre fogod venni, hogy blahblahblah-for-three-months.

Mert amikor először olvastam a jelentést, az agyam nem akarta 2017-nek látni! [NEVETÉS]

Április 17-től július 17-ig volt, így rengeteg „17” volt benne.

És az elmém eltüntette a 2017-et, mint a kezdő évet – rosszul értelmeztem, hogy „az idei év áprilistól júliusig*” [2022].

Azt gondoltam: „Hú, *három hónap*, de nem vették észre.”

És akkor az első megjegyzés a cikkhez az volt, „Ahm [KÖHÖGÉS]. Valójában *17.* április 2017-én volt.

Wow!

De valaki 17. július 2022-én kitalálta, és a Slack – becsületére legyen mondva – még aznap kijavította.

Például: "Ó, bébi, mire gondoltunk?!"

Szóval ez a rossz hír.

A jó hír az, hogy legalább *kivonatolt* jelszavak voltak.

És nem csak kivonatolt, hanem *sózott*, ahol egyedileg kiválasztott, felhasználónként véletlenszerű adatokat keverünk a jelszóval.

Ennek az ötlete kettős.

Az egyik, ha két ember ugyanazt a jelszót választja, nem ugyanazt a hash-t kapják, így nem lehet következtetéseket levonni a hash adatbázis áttekintésével.

Másodszor, nem lehet előre kiszámítani egy szótárt az ismert kivonatokból az ismert bemenetekhez, mert minden egyes jelszóhoz külön szótárt kell létrehozni *minden sóhoz*.

Tehát nem triviális gyakorlat a kivonatolt jelszavak feltörése.

Ennek ellenére az egész ötlet az, hogy ezek nem nyilvánosak.

Kivonják és sózzák * arra az esetre, ha kifolynak, nem * azért, hogy kifolyhassanak.

Szóval, tojás Slack arcára!

Slack szerint körülbelül 200 felhasználóból egy, azaz 0.5%-a érintett.

De ha Ön Slack-felhasználó, akkor azt feltételezném, hogy ha öt évig nem vették észre, hogy kivonatolt jelszavakat szivárogtatnak ki, akkor talán nem is sorolták fel teljesen az érintettek listáját.

Tehát menjen, és változtassa meg a jelszavát… azt is megteheti.

---

DOUG.  Rendben, azt is mondjuk: ha nem használ jelszókezelőt, fontolja meg annak beszerzését; és kapcsold be a 2FA-t, ha tudod.

---

KACSA.  Azt hittem, tetszeni fog, Doug.

---

DOUG.  Igen!

És akkor, ha Ön Slack vagy a társaság kedveli, válassza a jó hírű só-hash-and-stretch algoritmus amikor saját maga kezeli a jelszavakat.

---

KACSA.  Igen.

Slack válaszában az a nagy dolog, és amiről azt hittem, hogy hiányzott, hogy csak annyit mondtak: „Ne aggódjon, nem csak a jelszavakat kivonatoltattuk, hanem sóztuk is.”

Azt tanácsolom, hogy ha ilyen jogsértésen érnek, akkor legyen hajlandó deklarálni a sózáshoz és kivonatoláshoz használt algoritmust vagy folyamatot, és ideális esetben az ún. nyújtás, ahol nem csak egyszer, de talán 100,000 XNUMX-szer is kivonatolja a sózott jelszót, hogy lelassítson bármilyen szótári vagy brute force támadást.

És ha megadod, hogy milyen algoritmust használsz és milyen paraméterekkel... pl. PBKDF2, bcrypt, scrypt, Argon2 – ezek a legismertebb „só-hash-stretch” jelszó-algoritmusok.

Ha ténylegesen megadja, hogy milyen algoritmust használ, akkor: [A] nyitottabb lesz, és [B] lehetőséget ad a probléma potenciális áldozatainak, hogy maguk értékeljék, szerintük mennyire lehetett veszélyes. .

És ez a fajta nyitottság valóban sokat segíthet.

Slack nem ezt tette.

Csak annyit mondtak: "Ó, megsózták és kimosták."

De azt nem tudjuk, hogy beleraktak-e két bájt sót, majd egyszer kivonták-e az SHA-1-gyel…

…vagy volt bennük valami, ami jobban ellenáll a repedésnek?

---

DOUG.  Ha ragaszkodunk a rossz dolgok témájához, azt látjuk, hogy egy olyan tendencia alakul ki, amely az embereket érinti rossz dolgokat beszúrni a GitHubba, csak hogy lássuk, mi történik, kockázatot téve ki…

…van még egy ilyen történetünk.

---

KACSA.  Igen, valaki, aki állítólag most megjelent a Twitteren, és azt mondta: „Ne aggódjatok, srácok, nem történt semmi baj. Ez csak kutatás céljából volt. Írok egy jelentést, tűnj ki a Blue Alertből.”

Szó szerint hamis GitHub-projektek ezreit hoztak létre a létező legális kód másolására, szándékosan beszúrva néhány rosszindulatú programra vonatkozó parancsot, mint például a "hívjon haza további utasításokért", és "a válasz törzsét végrehajtandó hátsó ajtó kódként értelmezzék", és hamar.

Tehát olyan dolgok, amelyek valóban árthatnak, ha telepíti valamelyik csomagot.

Legális neveket adni nekik…

…láthatólag kölcsönkérem egy valódi projekt végrehajtási történetét, így a dolog sokkal legálisabbnak tűnt, mint ahogyan azt egyébként várná, ha csak a következő szöveggel jelenne meg: „Hé, töltsd le ezt a fájlt. Tudod hogy akarod!"

Igazán?! Kutatás?? Ezt még nem tudtuk?!!?

Most már vitatkozhat: „Nos, a Microsoft, aki a GitHub tulajdonosa, mit csinálnak azzal, hogy az emberek ilyen könnyen feltölthetnek ilyen tartalmat?”

És ebben van némi igazság.

Talán jobb munkát végeznének a rosszindulatú programok távol tartásával.

De egy kicsit túlzásba esik, ha azt mondjuk: "Ó, ez az egész a Microsoft hibája."

Véleményem szerint még rosszabb azt mondani: „Igen, ez egy valódi kutatás; ez nagyon fontos; emlékeztetnünk kell az embereket, hogy ez megtörténhet."

Nos, [A] ezt már tudjuk, nagyon köszönjük, mert rengeteg ember csinált már ilyet; hangosan és világosan megkaptuk az üzenetet.

És [B] ez *nem* kutatás.

Ezzel szándékosan próbálják rávenni az embereket, hogy olyan kódot töltsenek le, amely a potenciális támadónak távirányítót ad, cserébe jelentésírási képességért.

Ez nekem inkább „nagy, kövér kifogásnak” hangzik, semmint jogos motivációnak a kutatáshoz.

Ezért azt javaslom, hogy ha úgy gondolja, hogy ez egy kutatás, és ha eltökélt szándéka, hogy valami hasonlót még egyszer megcsináljon, *ne számítson sok együttérzésre*, ha elkapnak.

---

DOUG.  Rendben – erre és az olvasói megjegyzésekre még visszatérünk a műsor végén, úgyhogy maradj ki.

De először beszéljünk róla közlekedési lámpák, és mi közük van a kiberbiztonsághoz.

---

KACSA.  Ahhh, igen! [NEVETÉS]

Nos, van egy dolog, amit TLP-nek hívnak, a Közlekedési lámpa protokoll.

A TLP pedig az, amit „emberi kiberbiztonsági kutatási protokollnak” nevezhetnénk, amely segít a másoknak elküldött dokumentumok felcímkézésében, hogy utalást adjon nekik arra vonatkozóan, hogy mit remélnek (és ami még fontosabb, mit remélnek) nem*) nem az adatokkal.

Konkrétan, milyen széles körben kell újra elosztani?

Ez olyan fontos dolog, hogy kijelenthetnéd a világnak?

Vagy ez potenciálisan veszélyes, vagy potenciálisan olyan dolgokat tartalmaz, amelyeket még nem akarunk nyilvánosságra hozni… szóval tartsd magadban?

És ezzel kezdődött: TLP:RED, ami azt jelentette: „Tartsd meg magadnak”; TLP:AMBER, ami azt jelentette, hogy „Körbeküldheti saját cégén belül vagy olyan ügyfelei számára, akiknek úgy gondolja, hogy ezt sürgősen tudniuk kell”; TLP:GREEN, ami azt jelentette: „Rendben, hagyhatja, hogy ez széles körben elterjedjen a kiberbiztonsági közösségen belül.”

És TLP:WHITE, ami azt jelentette: „Bárkinek elmondhatod.”

Nagyon hasznos, nagyon egyszerű: PIROS, BOSÁRNYA, ZÖLD… egy metafora, amely globálisan működik, anélkül, hogy azon kellene törődni, hogy mi a különbség a „titkos” és a „bizalmas”, illetve a „bizalmas” és a „besorolt” között, mindazok a bonyolult dolgok, amelyek sok törvény kell körülötte.

Nos, a TLP most kapott néhány módosítást.

Tehát, ha kiberbiztonsági kutatásokkal foglalkozik, győződjön meg róla, hogy tisztában van ezekkel.

TLP:WHITE megváltoztatták azt, amit valójában sokkal jobb kifejezésnek tartok, mert fehér rendelkezik mindezekkel a szükségtelen kulturális felhangokkal, amelyeket nélkülözhetünk a modern korban.

Szóval, TLP:WHITE éppen azzá vált TLP:CLEAR, ami szerintem sokkal jobb szó, mert azt mondja: „Egyértelmű, hogy használja ezeket az adatokat”, és ez a szándék nagyon világosan ki van fejezve. (Elnézést, nem tudtam ellenállni a szójátéknak.)

És van egy további réteg (így egy kicsit elrontotta a metaforát – ez most egy *öt* színű közlekedési lámpa!).

Van egy speciális szint, az úgynevezett TLP:AMBER+STRICT, és ez azt jelenti, hogy „Ezt megoszthatja vállalatán belül.”

Tehát előfordulhat, hogy meghívnak egy találkozóra, esetleg egy kiberbiztonsági cégnél dolgozik, és teljesen egyértelmű, hogy ezt meg kell mutatnia a programozóknak, esetleg az IT-csapatának, esetleg a minőségbiztosítással foglalkozó munkatársainak, hogy kutatásokat végezhessen a problémát, vagy foglalkozzon a megoldásával.

De TLP:AMBER+STRICT azt jelenti, hogy bár terjesztheti a szervezeten belül, *kérjük, ne mondja el ügyfeleinek vagy ügyfeleinek*, vagy akár a vállalaton kívüli személyeknek, akikről úgy gondolja, hogy tudniuk kell.

Kezdésként tartsa a szűkebb közösségben.

TLP:AMBER, mint korábban, azt jelenti: "Rendben, ha úgy érzi, el kell mondania az ügyfeleknek, megteheti."

És ez fontos lehet, mert néha érdemes tájékoztatni ügyfeleit: „Hé, megérkezett a javítás. A javítás megérkezése előtt meg kell tennie néhány óvintézkedést. De mivel ez egyfajta érzékeny, megkérhetjük, hogy még ne mondd el a világnak?”

Néha, ha túl korán mondjuk el a világnak, az valójában inkább a szélhámosok kezére játszik, mint a védőkre.

Tehát, ha Ön kiberbiztonsági válaszadó, azt javaslom, hogy tegye a következőket: https://www.first.org/tlp

---

DOUG.  És te tudod olvass erről bővebben az oldalunkon, nakedsecurity.sophos.com.

És ha valami más könnyű olvasmányt keres, felejtse el a kvantumkriptográfiát… továbblépünk posztkvantum kriptográfia, Pál!

---

KACSA.  Igen, már beszéltünk erről néhányszor a podcastban, nem?

A kvantumszámítógép gondolata, feltételezve, hogy elég erős és megbízható megépíthető, az, hogy bizonyos típusú algoritmusokat fel lehetne gyorsítani a technika jelenlegi állása szerint, akár a négyzetgyök hangjával… vagy ami még rosszabb, A probléma mai mértékének *logaritmusa*.

Más szóval, 2 helyett²⁵⁶ megpróbál egy adott hash-t tartalmazó fájlt keresni, akkor lehet, hogy csak ("csak"!) 2¹²⁸ megpróbálja, ami a négyzetgyök.

Nyilván sokkal gyorsabban.

A prímszámok szorzatainak faktorizálásával kapcsolatos problémák egy egész osztálya azonban az elmélet szerint feltörhető a mai idő *logaritmusában*, lazán szólva.

Tehát ahelyett, hogy mondjuk 2¹²⁸ nap a feltöréshez [SZÓL HOSSZABB, MINT AZ UNIVERZUM JELENLEGI KORA], előfordulhat, hogy mindössze 128 napba telhet a feltörés.

Vagy helyettesítheti a „napokat” „percekkel”, vagy bármi mással.

És sajnos ez a logaritmikus időalgoritmus (úgy nevezett Shor kvantumfaktorizációs algoritmusa)… ez elméletileg alkalmazható lenne néhány mai kriptográfiai technikára, nevezetesen a nyilvános kulcsú titkosításhoz használtakra.

És arra az esetre, ha ezek a kvantumszámítógépek megvalósíthatóvá válnának az elkövetkező néhány évben, talán már most elkezdhetnénk felkészülni azokra a titkosítási algoritmusokra, amelyek nem sebezhetők e két támadástípussal szemben?

Különösen a logaritmus, mert annyira felgyorsítja a potenciális támadásokat, hogy azok a kriptográfiai kulcsok, amelyekről jelenleg azt gondoljuk, hogy „Nos, ezt soha senki nem fogja kitalálni”, egy későbbi szakaszban felfedhetővé válhatnak.

Különben is, NIST, a Nemzeti Szabványügyi és Technológiai Intézet Az Egyesült Államokban több éve versenyt hirdet néhány nyilvános, szabadalmazatlan, alaposan átvizsgált algoritmus szabványosítására, amelyek ellenállnak ezeknek a mágikus kvantumszámítógépeknek, ha valaha is megjelennek.

Nemrég pedig négy algoritmust választottak, amelyeket most már készek szabványosítani.

Jó nevük van, Doug, úgyhogy fel kell olvasnom őket: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONés SPHINCS+. [NEVETÉS]

Szóval klassz nevük van, ha más nem.

De ugyanakkor a NIST úgy gondolta: „Nos, ez csak négy algoritmus. Annyit fogunk tenni, hogy kiválasztunk még négyet potenciális másodlagos jelöltként, és meglátjuk, hogy ezek közül valamelyik is sikeres lesz-e.”

Tehát jelenleg négy szabványosított algoritmus létezik, és négy olyan algoritmus, amelyek a jövőben szabványosodhatnak.

Vagy négyen *voltak* 5. július 2022-én, és az egyik az volt SIKE, röviden szinguláris izogén kulcs beágyazása.

(Több podcastra lesz szükségünk, hogy megmagyarázzuk a szuperszinguláris izogéneket, így nem fogunk zavarni. [NEVETÉS])

De sajnos ez, ami ott lógott a harc esélyével, hogy szabványosítsák, úgy néz ki, mintha helyrehozhatatlanul összetört volna, annak ellenére, hogy már legalább öt éve nyitva áll a nyilvánosság előtt.

Szerencsére tehát, mielőtt szabványosították volna, két belga kriptográfus rájött: „Tudod mit? Úgy gondoljuk, hogy megkerülhetjük ezt a számításokat, amelyek körülbelül egy órát vesznek igénybe, egy meglehetősen átlagos CPU-n, mindössze egyetlen mag használatával.”

---

DOUG.  Azt hiszem, jobb most megtudni, mint szabványosítás és a vadonba hozatal után?

---

KACSA.  Valóban!

Gondolom, ha a már szabványosított algoritmusok egyike lett volna, akkor hatályon kívül kell helyezniük a szabványt, és újat kellene kidolgozniuk?

Furcsának tűnik, hogy ezt öt évig nem vették észre.

De azt hiszem, ez az egész elképzelés a nyilvános ellenőrzésről: soha nem tudhatod, mikor üti el valaki azt a repedést, amelyre szükség van, vagy arra a kis ékre, amellyel behatolhat, és bebizonyíthatja, hogy az algoritmus nem olyan erős, mint eredetileg gondolták.

Jó emlékeztető, hogy ha * valaha is* arra gondolt, hogy saját kriptográfiáját köti össze…

---

DOUG.  [NEvet] Nem tettem!

---

KACSA.  ..annak ellenére, hogy a Naked Security podcastban N-szer elmondtuk: „Ne csináld!”

Ez legyen a végső emlékeztető arra, hogy még ha valódi szakértők olyan algoritmust állítanak is ki, amelyet egy globális versenyben öt évig nyilvánosan vizsgálnak, ez még mindig nem biztosít elegendő időt a meglehetősen rossznak bizonyuló hibák feltárására.

Szóval biztosan nem néz ki jól ehhez SIKE algoritmus.

És ki tudja, talán visszavonják?

---

DOUG.  Figyelni fogunk erre.

És ahogy a nap lassan lenyugszik e heti műsorunkon, itt az ideje, hogy hallgassunk az egyik olvasónktól a GitHub-történettel kapcsolatban, amelyet korábban megbeszéltünk.

Rabol szerint:

„Van egy kis kréta és sajt a megjegyzésekben, és utálom kimondani, de őszintén látom az érvelés mindkét oldalát. Veszélyes, problémás, idő- és erőforrásigényes? Igen, természetesen az. A bűnözői beállítottságú típusok ezt tennék? Igen igen ez az. Emlékeztetőül emlékeztet mindenkit, aki GitHubot vagy bármilyen más kódtároló rendszert használ, hogy a biztonságos internetezés egészséges cinizmust és paranoiát igényel? Igen. Rendszergazdaként egy részem szeretné megtapsolni a fennálló kockázatot. Egy csomó fejlesztő rendszeradminisztrátoraként most meg kell győződnöm arról, hogy mostanában mindenki átvizsgálta a megkérdőjelezhető bejegyzéseket.

---

KACSA.  Igen, köszönöm, RobB, ezt a megjegyzést, mert azt hiszem, fontos látni az érvelés mindkét oldalát.

Voltak hozzászólók, akik csak azt mondták: „Mi a fene ezzel a probléma? Ez nagyszerű!"

Egy ember azt mondta: „Nem, valójában ez a tollteszt jó és hasznos. Örülj, hogy ezeket most leleplezték, ahelyett, hogy egy tényleges támadótól emelnék fel csúnya fejüket.”

És a válaszom erre az, hogy "Nos, ez valójában egy támadás."

Csak most valaki kijött utána, és azt mondta: „Ó, nem, nem. Nincs sértődés! Őszintén szólva, nem voltam szemtelen.”

Nem hiszem, hogy köteles megvenni ezt a kifogást!

De egyébként ez nem penetrációs tesztelés.

A válaszom az volt, nagyon egyszerűen: „A felelős penetrációs tesztelők mindig [A] csak kifejezett engedélyt kaptak, [B] pedig az előzetesen kifejezetten megállapodott viselkedési korlátokon belül.”

Nem csak a saját szabályaidat alakítod ki, és erről már korábban is beszéltünk.

Szóval, ahogy egy másik hozzászóló mondta, ami szerintem a kedvenc megjegyzésem… – mondta Ecurb, „Szerintem valakinek házról házra kellene járnia, és ablakokat betörnie, hogy megmutassa, mennyire nem hatékonyak az ajtózárak. Ez lejárt. Valaki ugorjon erre, kérem."

És akkor, ha nem vettétek volna észre, hogy ez szatíra, emberek, mondja: "Nem!"

---

KACSA.  Úgy gondolom, hogy ez egy jó emlékeztető, és azt az ötletet kapom, hogy ha Ön GitHub-felhasználó, gyártóként és fogyasztóként is, akkor van olyan, amit megtehet.

Felsoroljuk őket a megjegyzésekben és a cikkben.

Például tegyen digitális aláírást minden commit-jára, így nyilvánvaló, hogy a változtatások Öntől származnak, és van valamilyen nyomon követhetőség.

És ne csak vakon fogyasszon dolgokat, mert keresést végzett, és úgy tűnt, hogy ez lehet a megfelelő projekt.

Igen, mindannyian tanulhatunk ebből, de vajon ez valóban tanításnak számít-e, vagy ez egy olyan dolog, amit mindenképpen meg kell tanulnunk?

Szerintem ez *nem* tanítás.

Csak *nem elég magas színvonalú* ahhoz, hogy kutatásnak számítson.

---

DOUG.  Remek vita a cikk körül, és köszönöm, hogy elküldted, Rob.

Ha van egy érdekes története, megjegyzése vagy kérdése, amelyet fel szeretne tenni, azt szívesen olvassuk a podcastban.

E-mailt küldhet tips@sophos.com; bármelyik cikkünkhöz hozzászólhat; vagy üss meg minket a közösségi oldalon: @NakedSecurity.

Ez a mai műsorunk – nagyon köszönjük, hogy meghallgatott.

Paul Ducklin esetében én Doug Aamoth vagyok, és a következő alkalomig emlékeztetlek arra, hogy…

---

MINDKÉT.  Maradjon biztonságban!

[ZENEI MODEM]