S3 Ep95: wyciek luzu, atak na Github i post-kwantowe krypto [Audio + Text]

Kliknij i przeciągnij poniższe fale dźwiękowe, aby przejść do dowolnego punktu. Również możesz słuchaj bezpośrednio na Soundcloudzie.

DOUG.  Wycieki Slack, niegrzeczny kod GitHub i kryptografia post-kwantowa.

Wszystko to i wiele więcej w podkaście Naked Security.

[MOM MUZYCZNY]

Witam wszystkich w podkaście.

Jestem Doug Aamoth.

Ze mną, jak zawsze, jest Paul Ducklin.

Paul, jak się masz dzisiaj?

---

KACZKA.  Super-duper, jak zwykle, Doug!

---

DOUG.  Jestem bardzo podekscytowany, że mogę dostać się na ten tydzień Historia technologii segment, ponieważ…

…byłeś tam, człowieku!

W tym tygodniu, 11 sierpnia…

---

KACZKA.  O nie!

Myślę, że grosz właśnie spadł…

---

DOUG.  Nie muszę nawet mówić roku!

11 sierpnia 2003 – świat zwrócił uwagę na robaka Blaster, atakującego systemy Windows 2000 i Windows XP.

Blaster, znany również jako Lovesan i MsBlast, wykorzystał przepełnienie bufora i jest prawdopodobnie najbardziej znany z wiadomości, „Billy Gates, dlaczego to umożliwiasz? Przestań zarabiać i napraw swoje oprogramowanie.”

Co się stało, Paul?

---

KACZKA.  Cóż, być może była to epoka wcześniej, kiedy tak poważnie traktowaliśmy bezpieczeństwo.

I na szczęście tego rodzaju błąd byłby obecnie znacznie, znacznie trudniejszy do wykorzystania: było to przepełnienie bufora oparte na stosie.

A jeśli dobrze pamiętam, serwerowe wersje systemu Windows były już budowane z tak zwanym ochrona stosu.

Innymi słowy, jeśli przepełnisz stos wewnątrz funkcji, to zanim funkcja powróci i spowoduje uszkodzenie uszkodzonego stosu, wykryje, że stało się coś złego.

Musi więc zamknąć szkodliwy program, ale złośliwe oprogramowanie nie może się uruchomić.

Ale ta ochrona nie była wówczas dostępna w klienckich wersjach systemu Windows.

I jak pamiętam, był to jeden z tych wczesnych złośliwych programów, które musiały zgadywać, którą wersję systemu operacyjnego posiadasz.

Czy jesteś na 2000? Czy jesteś na NT? Czy jesteś na XP?

A jeśli coś się pomyliło, wtedy ważna część systemu uległaby awarii i pojawiłoby się ostrzeżenie „Twój system zaraz się wyłączy”.

---

DOUG.  Ha, pamiętam te!

---

KACZKA.  Tak więc pojawiły się dodatkowe szkody, które dla wielu ludzi były oznaką, że infekcje cię wbijają…

…które mogą pochodzić z zewnątrz, tak jakbyś był tylko użytkownikiem domowym i nie miał w domu routera ani zapory sieciowej.

Ale jeśli znajdowałeś się w firmie, najprawdopodobniej atak pochodził od kogoś innego wewnątrz firmy, wysyłającego pakiety do Twojej sieci.

Tak więc, podobnie jak w przypadku ataku CodeRed, o którym mówiliśmy, który miał miejsce kilka lat wcześniej, w ostatnim podkaście, problem stanowiła sama skala, głośność i szybkość tej rzeczy.

---

DOUG.  No dobrze, to było jakieś 20 lat temu.

A jeśli cofniemy zegar do pięciu lat temu, to właśnie wtedy Slack zaczął przeciekać zaszyfrowane hasła. [ŚMIECH]

---

KACZKA.  Tak, Slack, popularne narzędzie do współpracy…

…posiada funkcję, w której możesz wysłać link z zaproszeniem do innych osób, aby dołączyły do ​​Twojej przestrzeni roboczej.

I wyobraź sobie: klikasz przycisk z napisem „Wygeneruj łącze”, a utworzy to rodzaj pakietu sieciowego, który prawdopodobnie zawiera w sobie kod JSON.

Jeśli kiedykolwiek miałeś zaproszenie na spotkanie Zoom, wiesz, że zawiera ono datę i godzinę, osobę, która Cię zaprasza, adres URL, którego możesz użyć do spotkania, kod dostępu i wszystko inne. rzeczy – jest tam całkiem sporo danych.

Zwykle nie zagłębia się w surowe dane, aby zobaczyć, co tam jest – klient po prostu mówi: „Hej, tu jest spotkanie, oto szczegóły. Czy chcesz zaakceptować/może/odrzucić?”

Okazało się, że kiedy robiłeś to ze Slackiem, jak mówisz, przez ponad pięć lat, w tym zaproszeniu zapakowane były obce dane, które nie były ściśle związane z samym zaproszeniem.

A więc nie URL, nie imię, nie datę, nie godzinę…

…ale *hasz hasła użytkownika zapraszającego* [ŚMIECH]

---

DOUG.  Hmmmmm

---

KACZKA.  Nie żartuję!

---

DOUG.  Brzmi źle…

---

KACZKA.  Tak, naprawdę tak, prawda?

Zła wiadomość jest taka, jak to się tam dostało?

A kiedy już tam był, jak u licha unikał zauważenia przez pięć lat i trzy miesiące?

W rzeczywistości, jeśli odwiedzisz artykuł o Naked Security i spojrzysz na pełny adres URL artykułu, zauważysz, że na końcu jest napisane: blahblahblah-for-three-months.

Bo kiedy pierwszy raz przeczytałem raport, mój umysł nie chciał widzieć go jako 2017! [ŚMIECH]

To było od 17 kwietnia do 17 lipca, więc było tam dużo „17”.

A mój umysł wymazał rok 2017 jako rok początkowy – błędnie odczytałem go jako „od kwietnia do lipca * tego roku*” [2022].

Pomyślałem: „Wow, *trzy miesiące* i nie zauważyli”.

A potem pierwszy komentarz do artykułu brzmiał: „Hem [kaszel]. Właściwie to było 17 kwietnia *2017*.”

Wow!

Ale ktoś rozgryzł to 17 lipca [2022], a Slack, trzeba przyznać, naprawił to tego samego dnia.

Na przykład: „O rany, o czym myśleliśmy?!”

To zła wiadomość.

Dobrą wiadomością jest to, że przynajmniej zostały *zaszyfrowane* hasła.

I nie były one po prostu haszowane, były *solone*, czyli mieszając unikatowo wybrane, losowe dane na użytkownika z hasłem.

Idea tego jest dwojaka.

Po pierwsze, jeśli dwie osoby wybiorą to samo hasło, nie otrzymają tego samego skrótu, więc nie można wnioskować, przeglądając bazę danych skrótów.

Po drugie, nie możesz wstępnie obliczyć słownika znanych skrótów dla znanych danych wejściowych, ponieważ musisz utworzyć oddzielny słownik dla każdego hasła *dla każdej soli*.

Złamanie zaszyfrowanych haseł nie jest więc trywialnym ćwiczeniem.

To powiedziawszy, cały pomysł polega na tym, że nie powinny one być przedmiotem publicznego rejestru.

Są haszowane i solone *na wypadek* przecieku, a nie *po to, by mogły* przeciekać.

Więc jajko na twarzy Slacka!

Slack twierdzi, że problem dotyczył około jednego na 200 użytkowników, czyli 0.5%.

Ale jeśli jesteś użytkownikiem Slacka, zakładam, że jeśli przez pięć lat nie zdawali sobie sprawy, że wyciekają zaszyfrowane hasła, być może nie wymienili również listy osób, których to dotyczy.

Więc idź i zmień swoje hasło… równie dobrze możesz.

---

DOUG.  OK, mówimy też: jeśli nie używasz menedżera haseł, rozważ jego zakup; i włącz 2FA, jeśli możesz.

---

KACZKA.  Myślałem, że ci się spodoba, Doug.

---

DOUG.  Tak!

A potem, jeśli jesteś Slackiem lub firmą, która go lubi, wybierz a renomowany algorytm salt-hash-and-stretch podczas samodzielnej obsługi haseł.

---

KACZKA.  Tak.

Wielką sprawą w odpowiedzi Slacka, której moim zdaniem brakowało, jest to, że po prostu powiedzieli: „Nie martw się, nie tylko haszowaliśmy hasła, ale także je soliliśmy”.

Moja rada jest taka, że ​​jeśli zostaniesz przyłapany na takim wyłomie, powinieneś chcieć zadeklarować algorytm lub proces użyty do solenia i haszowania, a najlepiej to, co się nazywa sięgnięcie, w którym nie tylko raz haszujesz solone hasło, ale być może haszujesz je 100,000 XNUMX razy, aby spowolnić wszelkiego rodzaju ataki słownikowe lub brute force.

A jeśli podasz, jakiego algorytmu używasz i z jakimi parametrami… na przykład, PBKDF2, bcrypt, scrypt, Argon2 – są to najbardziej znane algorytmy „salt-hash-stretch” haseł.

Jeśli faktycznie określisz, jakiego algorytmu używasz, wtedy: [A] jesteś bardziej otwarty, a [B] dajesz potencjalnym ofiarom problemu szansę na samodzielne oszacowanie, jak niebezpieczne według nich mogło to być .

A taka otwartość może bardzo pomóc.

Slack tego nie zrobił.

Powiedzieli tylko: „Och, były solone i haszowane”.

Ale nie wiemy, czy włożyli dwa bajty soli, a następnie zahaszowali je raz za pomocą SHA-1…

…a może mieli coś bardziej odpornego na pękanie?

---

DOUG.  Pozostając przy temacie złych rzeczy, zauważamy rozwijający się trend, w którym ludzie są wstrzykiwanie złych rzeczy do GitHub, żeby zobaczyć, co się stanie, narażając ryzyko…

…mamy kolejną z tych historii.

---

KACZKA.  Tak, ktoś, kto teraz podobno pojawił się na Twitterze i powiedział: „Nie martwcie się, nic się nie stało. To było tylko do badań. Napiszę raport, wyróżnij się z Blue Alert.

Stworzyli dosłownie tysiące fałszywych projektów GitHub, polegających na kopiowaniu istniejącego legalnego kodu, celowym wstawianiu tam niektórych poleceń złośliwego oprogramowania, takich jak „zadzwoń do domu w celu uzyskania dalszych instrukcji” i „interpretuj treść odpowiedzi jako kod backdoora do wykonania” oraz wkrótce.

Tak więc rzeczy, które naprawdę mogą zaszkodzić, jeśli zainstalowałeś jeden z tych pakietów.

Nadając im legalnie wyglądające imiona…

…pożyczając najwyraźniej historię commitów oryginalnego projektu, aby rzecz wyglądała o wiele bardziej legalnie, niż można by się spodziewać, gdyby pojawiła się po prostu z: „Hej, pobierz ten plik. Wiesz że chcesz!"

Naprawdę?! Badania?? Jeszcze tego nie wiedzieliśmy?!!?

Teraz możesz się spierać: „Cóż, Microsoft, który jest właścicielem GitHub, co oni robią, aby ludzie mogli tak łatwo przesyłać tego rodzaju rzeczy?”

I jest w tym trochę prawdy.

Może w pierwszej kolejności mogliby lepiej radzić sobie ze złośliwym oprogramowaniem.

Ale powiedzenie: „Och, to wszystko wina Microsoftu” jest trochę przesadzone.

Moim zdaniem jeszcze gorzej jest powiedzieć: „Tak, to są prawdziwe badania; to jest naprawdę ważne; musimy przypominać ludziom, że to może się zdarzyć”.

Cóż, [A] już to wiemy, dziękuję bardzo, ponieważ wiele osób zrobiło to wcześniej; otrzymaliśmy wiadomość głośną i wyraźną.

I [B] to *nie* badania.

Jest to celowo próba nakłonienia ludzi do pobrania kodu, który daje potencjalnemu napastnikowi zdalne sterowanie, w zamian za możliwość napisania raportu.

Dla mnie brzmi to bardziej jak „wielka, gruba wymówka” niż uzasadniony motywator do badań.

A więc moja rekomendacja jest taka, jeśli uważasz, że to *to* badania i jeśli jesteś zdeterminowany, aby zrobić coś takiego jeszcze raz, *nie oczekuj wiele sympatii*, jeśli zostaniesz złapany.

---

DOUG.  W porządku – wrócimy do tego, a czytelnik komentuje pod koniec programu, więc trzymaj się.

Ale najpierw porozmawiajmy o sygnalizacja świetlnai co mają wspólnego z cyberbezpieczeństwem.

---

KACZKA.  Ach, tak! [ŚMIAĆ SIĘ]

Cóż, jest coś, co nazywa się TLP, Protokół sygnalizacji świetlnej.

A TLP to coś, co można by nazwać „protokołem badań nad cyberbezpieczeństwem człowieka”, który pomaga oznaczać dokumenty wysyłane do innych osób, aby dać im wskazówkę, co masz nadzieję, że będą (i, co ważniejsze, co masz nadzieję, że będą) * nie*) zrobić z danymi.

W szczególności, jak szeroko mają go redystrybuować?

Czy to jest coś tak ważnego, że mógłbyś to ogłosić światu?

A może jest to potencjalnie niebezpieczne, czy może zawiera pewne rzeczy, których nie chcemy jeszcze upubliczniać… więc zachowaj to dla siebie?

A zaczęło się od: TLP:RED, co oznaczało „Zachowaj to dla siebie”; TLP:AMBER, co oznaczało: „Możesz rozpowszechniać go we własnej firmie lub wśród swoich klientów, którzy Twoim zdaniem mogą pilnie o tym wiedzieć”; TLP:GREEN, co oznaczało: „OK, możesz pozwolić, aby to krążyło szeroko w społeczności cyberbezpieczeństwa”.

oraz TLP:WHITE, co oznaczało: „Możesz powiedzieć każdemu”.

Bardzo przydatne, bardzo proste: CZERWONY, BURSZTYNOWY, ZIELONY… metafora, która działa globalnie, nie martwiąc się o to, jaka jest różnica między „tajemnicą” a „poufnym” i jaka jest różnica między „poufnymi” a „sklasyfikowanymi”, wszystkie te skomplikowane rzeczy, które potrzebuje całego mnóstwa praw wokół niego.

Cóż, TLP właśnie dostał kilka modyfikacji.

Jeśli więc interesujesz się badaniami nad cyberbezpieczeństwem, upewnij się, że jesteś tego świadomy.

TLP:WHITE został zmieniony na znacznie lepszy termin, ponieważ biały ma wszystkie te niepotrzebne kulturowe podteksty, bez których możemy się obejść w epoce nowożytnej.

Więc, TLP:WHITE właśnie się stało TLP:CLEAR, co moim zdaniem jest o wiele lepszym słowem, ponieważ mówi: „Możesz używać tych danych”, a intencja jest, hm, bardzo wyraźnie określona. (Przepraszam, nie mogłem się oprzeć kalamburowi.)

I jest dodatkowa warstwa (więc trochę popsuła metaforę – teraz jest to *pięciokolorowa sygnalizacja świetlna!).

Istnieje specjalny poziom zwany TLP:AMBER+STRICT, a to oznacza: „Możesz udostępnić to w swojej firmie”.

Więc możesz zostać zaproszony na spotkanie, może pracujesz dla firmy zajmującej się cyberbezpieczeństwem i jest całkiem jasne, że będziesz musiał pokazać to programistom, może swojemu zespołowi IT, może pracownikom ds. zapewnienia jakości, aby móc przeprowadzić badania problem lub zająć się jego naprawą.

Ale TLP:AMBER+STRICT oznacza to, że chociaż możesz rozpowszechniać je w swojej organizacji, *proszę nie informować o tym swoich klientów ani klientów*, a nawet osób spoza firmy, o których Twoim zdaniem mogą być potrzebne informacje.

Na początek trzymaj go w ramach ściślejszej społeczności.

TLP:AMBER, tak jak poprzednio, oznacza „OK, jeśli czujesz, że musisz powiedzieć swoim klientom, możesz”.

A to może być ważne, ponieważ czasami możesz chcieć poinformować swoich klientów: „Hej, nadchodzi poprawka. Zanim pojawi się poprawka, musisz podjąć pewne środki ostrożności. Ale ponieważ jest trochę drażliwy, możemy prosić, abyś jeszcze nie mówił światu?”

Czasami powiedzenie światu zbyt wcześnie jest bardziej w rękach oszustów niż w rękach obrońców.

Tak więc, jeśli odpowiadasz na cyberbezpieczeństwo, sugeruję, abyś poszedł: https://www.first.org/tlp

---

DOUG.  I możesz przeczytaj więcej na ten temat na naszej stronie, nagasecurity.sophos.com.

A jeśli szukasz innej lektury, zapomnij o kryptografii kwantowej… przechodzimy do kryptografia post kwantowa, Paweł!

---

KACZKA.  Tak, rozmawialiśmy o tym kilka razy wcześniej w podkaście, prawda?

Ideą komputera kwantowego, zakładając, że można by zbudować wystarczająco mocny i niezawodny komputer, jest to, że niektóre rodzaje algorytmów można przyspieszyć w stosunku do obecnego stanu techniki, albo zgodnie z pierwiastkiem kwadratowym… albo, co gorsza, *logarytm* skali problemu dzisiaj.

Innymi słowy, zamiast brać 2²⁵⁶ próbuje znaleźć plik z określonym hashem, możesz to zrobić po prostu („tylko”!) 2¹²⁸ próbuje, czyli pierwiastek kwadratowy.

Zdecydowanie dużo szybciej.

Ale jest cała klasa problemów związanych z faktoryzacją produktów liczb pierwszych, które według teorii mogą zostać rozbite w *logarytmie* czasu, który zajmują dzisiaj, mówiąc luźno.

Więc zamiast brać powiedzmy 2¹²⁸ dni do złamania [ZNACZNIE DŁUŻEJ NIŻ OBECNY WIEK WSZECHŚWIATA], złamanie może zająć tylko 128 dni.

Możesz też zamienić „dni” na „minuty” lub cokolwiek innego.

I niestety ten logarytmiczny algorytm czasu (zwany Algorytm faktoryzacji kwantowej Shora)… teoretycznie można to zastosować do niektórych dzisiejszych technik kryptograficznych, zwłaszcza tych używanych do kryptografii klucza publicznego.

I na wypadek, gdyby te urządzenia do obliczeń kwantowych stały się wykonalne w ciągu najbliższych kilku lat, może powinniśmy zacząć przygotowywać się już teraz na algorytmy szyfrowania, które nie są podatne na te dwie konkretne klasy ataków?

W szczególności logarytmiczna, ponieważ przyspiesza potencjalne ataki tak bardzo, że klucze kryptograficzne, o których obecnie myślimy: „No cóż, nikt nigdy tego nie odkryje”, mogą stać się możliwe do ujawnienia na późniejszym etapie.

W każdym razie, NIST, Narodowy Instytut Norm i Technologii w USA od kilku lat organizuje konkurs, aby spróbować ujednolicić niektóre publiczne, nieopatentowane, dokładnie przeanalizowane algorytmy, które będą odporne na te magiczne komputery kwantowe, jeśli kiedykolwiek się pojawią.

A ostatnio wybrali cztery algorytmy, które są teraz gotowe do standaryzacji.

Mają fajne imiona, Doug, więc muszę je przeczytać: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON, SPHINCS+. [ŚMIECH]

Więc mają fajne nazwy, jeśli nic więcej.

Ale w tym samym czasie NIST doszedł do wniosku: „Cóż, to tylko cztery algorytmy. To, co zrobimy, to wybierzemy jeszcze czterech jako potencjalnych drugorzędnych kandydatów i zobaczymy, czy któryś z nich również powinien przejść.

Tak więc są teraz cztery ustandaryzowane algorytmy i cztery algorytmy, które mogą zostać ustandaryzowane w przyszłości.

Albo *były* cztery 5 lipca 2022 r., a jeden z nich był SIKE, skrót od enkapsulacja z kluczem izogenicznym nadosobliwym.

(Będziemy potrzebować kilku podcastów, aby wyjaśnić izogenię nadosobniczą, więc nie będziemy się tym zawracać. [ŚMIECH])

Ale niestety ten, który wisiał tam z szansą na ujednolicenie, wygląda na to, że został nieodwracalnie zepsuty, mimo że już od co najmniej pięciu lat był otwarty na publiczną kontrolę.

Na szczęście, tuż przed ujednoliceniem, dwóch belgijskich kryptografów stwierdziło: „Wiesz co? Uważamy, że możemy to obejść za pomocą obliczeń, które trwają około godziny na dość przeciętnym procesorze, wykorzystującym tylko jeden rdzeń”.

---

DOUG.  Myślę, że lepiej jest się o tym przekonać teraz, niż po ustandaryzowaniu i wypuszczeniu na wolność?

---

KACZKA.  W rzeczy samej!

Domyślam się, że gdyby to był jeden z algorytmów, który już się ustandaryzował, musieliby uchylić standard i wymyślić nowy?

Wydaje się dziwne, że nie zauważono tego przez pięć lat.

Ale myślę, że na tym polega cała idea publicznej kontroli: nigdy nie wiadomo, kiedy ktoś może po prostu uderzyć w szczelinę, która jest potrzebna, lub w mały klin, którego mogą użyć, aby się włamać i udowodnić, że algorytm nie jest tak silny, jak pierwotnie sądzono.

Dobre przypomnienie, że jeśli *kiedykolwiek* pomyślałeś o zrobieniu własnej kryptografii…

---

DOUG.  [ŚMIECH] Nie mam!

---

KACZKA.  ..pomimo tego, że w podkaście Naked Security N razy mówiliśmy: „Nie rób tego!”

Powinno to być ostatecznym przypomnieniem, że nawet jeśli prawdziwi eksperci przedstawią algorytm, który przez pięć lat podlega publicznej kontroli w globalnym konkursie, to i tak nie musi to zapewnić wystarczająco dużo czasu na ujawnienie wad, które okazują się bardzo złe.

Więc na pewno nie wygląda to dobrze SIKE algorytm.

A kto wie, może zostanie wycofany?

---

DOUG.  Będziemy tego pilnować.

A ponieważ słońce powoli zachodzi w naszym programie w tym tygodniu, nadszedł czas, aby usłyszeć od jednego z naszych czytelników na temat historii GitHub, o której rozmawialiśmy wcześniej.

Rabować pisze,:

„W komentarzach jest trochę kredy i sera i nienawidzę tego mówić, ale naprawdę widzę obie strony sporu. Czy jest to niebezpieczne, kłopotliwe, czasochłonne i pochłaniające zasoby? Tak, oczywiście, że tak. Czy to właśnie zrobiliby kryminalni ludzie? Tak tak to jest. Czy jest to przypomnienie dla każdego, kto korzysta z GitHub lub innego systemu repozytorium kodu, że bezpieczne podróżowanie po Internecie wymaga zdrowego stopnia cynizmu i paranoi? TAk. Jako administrator, część mnie chce przyklasnąć ekspozycji na ryzyko. Jako administrator w grupie programistów, muszę się teraz upewnić, że wszyscy ostatnio szukali podejrzanych wpisów”.

---

KACZKA.  Tak, dziękuję RobB za ten komentarz, ponieważ myślę, że ważne jest, aby zobaczyć obie strony sporu.

Byli komentatorzy, którzy po prostu mówili: „Co do cholery jest z tym problemem? To jest świetne!"

Jedna osoba powiedziała: „Nie, właściwie to testy piórkowe są dobre i przydatne. Ciesz się, że są teraz odsłonięte, zamiast podnosić swoją brzydką głowę przed prawdziwym napastnikiem.

A moja odpowiedź na to jest taka: „Cóż, to właściwie *jest* atak”.

Po prostu ktoś wyszedł później i powiedział: „O nie, nie. Żadna krzywda! Szczerze mówiąc, nie byłem niegrzeczny”.

Myślę, że nie musisz kupować tej wymówki!

Ale i tak nie są to testy penetracyjne.

Moja odpowiedź była bardzo prosta: „Odpowiedzialni testerzy penetracji zawsze działają [A] po otrzymaniu wyraźnej zgody, a [B] w granicach behawioralnych wyraźnie wcześniej uzgodnionych”.

Nie tylko ustalasz własne zasady, o czym rozmawialiśmy już wcześniej.

Tak więc, jak powiedział inny komentator, co jest moim ulubionym komentarzem… Ecurb powiedział, „Myślę, że ktoś powinien chodzić od domu do domu i rozbijać okna, aby pokazać, jak naprawdę nieskuteczne są zamki do drzwi. To jest przeterminowane. Niech ktoś wskoczy na to, proszę.

A potem, na wypadek, gdybyście nie zdawali sobie sprawy, że to satyra, ludzie, mówi: "Nie!"

---

KACZKA.  Wyobrażam sobie, że to dobre przypomnienie i myślę, że jeśli jesteś użytkownikiem GitHub, zarówno jako producent, jak i konsument, są rzeczy, które możesz zrobić.

Wymieniamy je w komentarzach i artykule.

Na przykład umieść podpis cyfrowy na wszystkich swoich zatwierdzeniach, aby było oczywiste, że zmiany pochodziły od Ciebie i że istnieje pewien rodzaj identyfikowalności.

I nie tylko ślepo konsumuj rzeczy, ponieważ przeprowadziłeś wyszukiwanie i „wyglądało na to”, że może to być właściwy projekt.

Tak, wszyscy możemy się z tego uczyć, ale czy faktycznie liczy się to jako uczenie nas, czy jest to po prostu coś, czego i tak powinniśmy się nauczyć?

Myślę, że to *nie* nauczanie.

To po prostu *nie jest wystarczająco wysoki*, aby liczyć się jako badanie.

---

DOUG.  Świetna dyskusja wokół tego artykułu i dziękuję za przesłanie, Rob.

Jeśli masz ciekawą historię, komentarz lub pytanie, które chciałbyś przesłać, chętnie przeczytamy o tym w podkaście.

Możesz wysłać e-mailem tips@sophos.com; możesz skomentować dowolny z naszych artykułów; lub napisz do nas na portalach społecznościowych: @NakedSecurity.

To nasz występ na dzisiaj – bardzo dziękuję za wysłuchanie.

Dla Paula Ducklina jestem Doug Aamoth i przypominam, do następnego razu, aby…

---

OBIE.  Bądź bezpieczny!

[MOM MUZYCZNY]