S3 Ep95: Gevşek sızıntı, Github saldırısı ve kuantum sonrası kripto [Ses + Metin]

Herhangi bir noktaya atlamak için aşağıdaki ses dalgalarına tıklayın ve sürükleyin. Ayrıca doğrudan dinle Soundcloud'da.

DOUG.  Gevşek sızıntılar, yaramaz GitHub kodu ve kuantum sonrası şifreleme.

Tüm bunlar ve çok daha fazlası Naked Security podcast'inde.

[MÜZİKAL MODEM]

Podcast'e hoş geldiniz millet.

Ben Doug Aamoth'um.

Her zamanki gibi yanımda Paul Ducklin var.

Paul, bugün nasılsın?

---

ÖRDEK.  Her zamanki gibi süper kandırılmış Doug!

---

DOUG.  Bu haftaya geleceğim için çok heyecanlıyım Teknoloji Geçmişi bölüm çünkü...

...oradaydın adamım!

Bu hafta 11 Ağustos…

---

ÖRDEK.  Oh hayır!

Sanırım jeton düştü...

---

DOUG.  Yılı söylememe gerek bile yok!

11 Ağustos 2003 - dünya, Windows 2000 ve Windows XP sistemlerini etkileyen Blaster solucanını fark etti.

Lovesan ve MsBlast olarak da bilinen Blaster, arabellek taşmasından yararlandı ve belki de en çok şu mesajla tanınır: "Billy Gates, bunu neden mümkün kılıyorsun? Para kazanmayı bırakın ve yazılımınızı düzeltin.”

Ne oldu Paul?

---

ÖRDEK.  Şey, belki de güvenliği çok ciddiye aldığımız bir dönemdi.

Ve neyse ki, bu tür bir hatadan yararlanmak bugünlerde çok, çok daha zor olurdu: yığın tabanlı bir arabellek taşmasıydı.

Ve doğru hatırlıyorsam, Windows'un sunucu sürümleri zaten yığın koruması.

Başka bir deyişle, bir fonksiyonun içindeki yığını taşarsanız, işlev geri dönmeden ve bozuk yığınla hasar vermeden önce, kötü bir şey olduğunu algılayacaktır.

Bu nedenle, rahatsız edici programı kapatması gerekir, ancak kötü amaçlı yazılım çalışmaz.

Ancak bu koruma, o sırada Windows'un istemci sürümlerinde yoktu.

Ve hatırladığım kadarıyla, işletim sisteminin hangi sürümüne sahip olduğunuzu tahmin etmesi gereken o eski kötü amaçlı yazılımlardan biriydi.

2000'de misin? NT'de misin? XP'de misin?

Ve yanlış olursa, sistemin önemli bir parçası çökecek ve “Sisteminiz kapanmak üzere” uyarısını alacaksınız.

---

DOUG.  Hah, bunları hatırlıyorum!

---

ÖRDEK.  Yani, birçok insan için enfeksiyonlar tarafından dövüldüğünüzün işareti olan ikincil bir hasar vardı…

…bu dışarıdan olabilir, sanki sadece bir ev kullanıcısıymışsınız ve evde bir yönlendiriciniz veya güvenlik duvarınız yokmuş gibi.

Ancak bir şirketin içindeyseniz, büyük olasılıkla saldırı, şirket içindeki başka birinden gelip ağınıza paketler yayacaktı.

Bundan birkaç yıl önce, son bir podcast'te bahsettiğimiz CodeRed saldırısına çok benziyor, asıl sorun bu şeyin ölçeği, hacmi ve hızıydı.

---

DOUG.  Pekala, bu yaklaşık 20 yıl önceydi.

Ve zamanı beş yıl öncesine döndürürsek, işte o zaman Slack sızmaya başladı karma şifreler. [Gülüşmeler]

---

ÖRDEK.  Evet, popüler işbirliği aracı Slack…

…çalışma alanınıza katılmaları için diğer kişilere davet bağlantısı gönderebileceğiniz bir özelliği vardır.

Ve hayal edin: “Bir bağlantı oluştur” yazan bir düğmeye tıklarsınız ve muhtemelen içinde JSON bulunan bir tür ağ paketi oluşturur.

Daha önce bir Zoom toplantı daveti aldıysanız, bunun bir tarihi ve saati, sizi davet eden kişi ve toplantı için kullanabileceğiniz bir URL, bir şifre ve tüm bunlar olduğunu bileceksiniz. şeyler - orada oldukça fazla veri var.

Normalde, orada ne olduğunu görmek için ham verilere girmezsiniz – müşteri sadece “Hey, işte bir toplantı, işte ayrıntılar. Kabul etmek / Belki / Reddetmek istiyor musunuz?”

Slack ile bunu yaptığınızda, dediğiniz gibi, beş yıldan fazla bir süredir bu davetiyede paketlenmiş, davetiyenin kendisiyle kesinlikle alakalı olmayan yabancı veriler olduğu ortaya çıktı.

Yani bir URL değil, bir isim değil, bir tarih değil, bir saat değil…

…ama *davet eden kullanıcının parola karması* [Gülüşme]

---

DOUG.  Hmmmmm.

---

ÖRDEK.  Şaka yapmıyorum!

---

DOUG.  Kulağa kötü geliyor…

---

ÖRDEK.  Evet, gerçekten öyle değil mi?

Kötü haber şu ki, bu oraya nasıl girdi?

Ve bir kez oradayken, beş yıl üç ay boyunca nasıl olup da fark edilmedi?

Aslında, Çıplak Güvenlik ile ilgili makaleyi ziyaret edip şuraya bakarsanız, tam URL makalenin sonunda şunu yazdığını fark edeceksiniz, blahblahblah-for-three-months.

Çünkü raporu ilk okuduğumda aklım 2017 olarak görmek istemedi! [Gülüşmeler]

17 Nisan'dan 17 Temmuz'a kadardı ve orada bir sürü “17” vardı.

Ve zihnim 2017'yi başlangıç ​​yılı olarak sildi – onu “bu yılın *nisanından temmuza* kadar*” [2022] olarak yanlış okudum.

“Vay canına, *üç ay* ve fark etmemişler” diye düşündüm.

Ve sonra makaleye yapılan ilk yorum, “Ahem [ÖSEK]. Aslında 17 Nisan *2017* idi.”

Wow!

Ancak biri bunu 17 Temmuz [2022]'de çözdü ve Slack, kredisine göre aynı gün düzeltti.

"Aman Tanrım, ne düşünüyorduk?" Gibi.

Yani kötü haber bu.

İyi haber şu ki, en azından şifreler *karıştırılmış*.

Ve bunlar sadece karma değil, *tuzlu* idiler; bu, benzersiz bir şekilde seçilmiş, kullanıcı başına rastgele verileri parolayla karıştırdığınız yerdir.

Bunun fikri iki yönlüdür.

Birincisi, iki kişi aynı şifreyi seçerse, aynı hash'i almazlar, bu yüzden hash veritabanına bakarak herhangi bir çıkarım yapamazsınız.

İkincisi, bilinen girdiler için bilinen karmaların sözlüğünü önceden hesaplayamazsınız, çünkü her parola için *her tuz* için ayrı bir sözlük oluşturmanız gerekir.

Yani karma şifreleri kırmak önemsiz bir alıştırma değil.

Bunu söyledikten sonra, bütün fikir, bunların bir kamu kaydı meselesi olmaması gerektiğidir.

Sızdırabilmeleri için * değil, sızdırmaları durumunda * hash ve tuzlanırlar.

Öyleyse, Slack'in yüzüne yumurta!

Slack, yaklaşık 200 kullanıcıdan birinin veya %0.5'inin etkilendiğini söylüyor.

Ancak bir Slack kullanıcısıysanız, beş yıl boyunca karma şifreleri sızdırdıklarını fark etmeseler, belki de etkilenen kişilerin listesini tam olarak saymadıklarını varsayabilirim.

Öyleyse git ve yine de şifreni değiştir… sen de yapabilirsin.

---

DOUG.  Tamam, ayrıca şunu da söylüyoruz: Bir parola yöneticisi kullanmıyorsanız, bir tane edinmeyi düşünün; ve mümkünse 2FA'yı açın.

---

ÖRDEK.  Bunu seveceğini düşündüm, Doug.

---

DOUG.  Evet ediyorum!

Ardından, Slack veya onun gibi bir şirketseniz, bir saygın tuz-karma-ve-uzatma algoritması şifreleri kendiniz işlerken.

---

ÖRDEK.  Evet.

Slack'in yanıtındaki büyük sorun ve eksik olduğunu düşündüğüm şey, "Endişelenme, sadece şifreleri elde etmekle kalmadık, onları da tuzladık" demeleriydi.

Benim tavsiyem, böyle bir ihlale yakalanırsanız, tuzlama ve karma için kullandığınız algoritmayı veya işlemi ve ayrıca ideal olarak ne denir? germe, ki bu sadece tuzlu parolayı bir kez hash etmezsiniz, ama belki de her türlü sözlük veya kaba kuvvet saldırısını yavaşlatmak için 100,000 kez hash yaparsınız.

Ve hangi algoritmayı ve hangi parametrelerle kullandığınızı belirtirseniz.. örneğin, PBKDF2, bcrypt, scrypt, Argon2 – bunlar en iyi bilinen parola “tuz-hash-stretch” algoritmalarıdır.

Gerçekten hangi algoritmayı kullandığınızı belirtirseniz, o zaman: [A] daha açık olursunuz ve [B] sorunun potansiyel kurbanlarına bunun ne kadar tehlikeli olabileceğini düşündüklerini değerlendirmeleri için bir şans verirsiniz. .

Ve bu tür bir açıklık aslında çok yardımcı olabilir.

Slack bunu yapmadı.

Sadece, "Ah, tuzlanmışlar ve haşlanmışlar" dediler.

Ama bilmediğimiz şey, iki baytlık tuz koyup, sonra onları bir kez SHA-1 ile hash ettiler mi…

…ya da çatlamaya karşı biraz daha dirençli bir şeyleri mi vardı?

---

DOUG.  Kötü şeyler konusuna bağlı kalarak, insanların içinde bulunduğu bir trendin geliştiğini fark ediyoruz. GitHub'a kötü şeyler enjekte etmek, sadece ne olduğunu görmek için, riski ortaya çıkarmak…

…o hikayelerden bir tane daha var.

---

ÖRDEK.  Evet, şimdi iddiaya göre biri Twitter'a çıkıp "Merak etmeyin arkadaşlar bir zararı yok. Sadece araştırma içindi. Bir rapor yazacağım, Mavi Uyarı'dan sıyrılacağım."

Mevcut yasal kodu kopyalamaya, kasıtlı olarak "daha fazla talimat için evi ara" ve "yanıtın gövdesini yürütülecek arka kapı kodu olarak yorumla" gibi bazı kötü amaçlı yazılım komutları eklemeye dayanan binlerce sahte GitHub projesi oluşturdular ve yakında.

Yani, bu paketlerden birini kurduysanız gerçekten zarar verebilecek şeyler.

Onlara okunaklı görünen isimler vermek…

…görünüşe göre, gerçek bir projenin taahhüt geçmişini ödünç almak, böylece bu şey, ortaya çıktığında beklediğinizden çok daha yasal görünüyordu, “Hey, bu dosyayı indirin. İstediğini biliyorsun!"

Yok canım?! Araştırma?? Bunu zaten bilmiyor muyduk?!!?

Şimdi, "Eh, Microsoft, GitHub'ın sahibi, insanların bu tür şeyleri yüklemesini bu kadar kolaylaştıran ne yapıyorlar?" diye tartışabilirsiniz.

Ve bunda bazı gerçekler var.

Belki de ilk etapta kötü amaçlı yazılımları dışarıda tutmak için daha iyi bir iş çıkarabilirler.

Ama "Ah, hepsi Microsoft'un suçu" demek biraz aşırıya kaçıyor.

Bana göre, “Evet, bu gerçek bir araştırma; bu gerçekten önemli; İnsanlara bunun olabileceğini hatırlatmalıyız.”

Pekala, [A] bunu zaten biliyoruz, çok teşekkür ederim, çünkü bir sürü insan bunu daha önce yaptı; mesajı yüksek sesle ve net olarak aldık.

Ve [B] bu araştırma *değildir*.

Bu, kasıtlı olarak, bir rapor yazma yeteneği karşılığında olası bir saldırgana uzaktan kontrol sağlayan kodu indirmeleri için insanları kandırmaya çalışıyor.

Bu bana araştırma için meşru bir motivasyondan çok “büyük bir bahane” gibi geliyor.

Ve benim tavsiyem, eğer bunun bir araştırma* olduğunu düşünüyorsanız ve böyle bir şeyi yeniden yapmaya kararlıysanız, yakalanırsanız *çok fazla sempati beklemeyin*.

---

DOUG.  Pekala - buna ve okuyucu yorumlarına gösterinin sonunda geri döneceğiz, bu yüzden burada kalın.

Ama önce şunu konuşalım trafik ışıklarıve bunların siber güvenlikle ne ilgisi var.

---

ÖRDEK.  Evet! [KAHKAHA]

TLP diye bir şey var, Trafik Işığı Protokolü.

Ve TLP, diğer insanlara gönderdiğiniz belgeleri etiketlemenize, onlara ne yapacaklarını umduğunuza (ve daha da önemlisi, ne umduğunuza) dair bir ipucu vermenize yardımcı olan bir "insan siber güvenlik araştırma protokolü" diyebileceğiniz şeydir. değil*) verilerle yapın.

Özellikle, ne kadar geniş bir alana yeniden dağıtmaları gerekiyor?

Bu, dünyaya ilan edebileceğin kadar önemli bir şey mi?

Yoksa bu potansiyel olarak tehlikeli mi, yoksa henüz kamuya açıklanmasını istemediğimiz bazı şeyleri potansiyel olarak içeriyor mu… bu yüzden kendinize saklayın?

Ve şöyle başladı: TLP:RED"Kendine sakla" anlamına gelen; TLP:AMBER“Bunu kendi şirketinizde veya acilen bilmesi gerektiğini düşündüğünüz müşterilerinize dağıtabilirsiniz” anlamına gelen; TLP:GREEN, bu da "Tamam, bunun siber güvenlik topluluğu içinde geniş çapta yayılmasına izin verebilirsiniz" anlamına geliyordu.

Ve TLP:WHITE, bu da "Herkese söyleyebilirsin" anlamına geliyordu.

Çok kullanışlı, çok basit: KIRMIZI, AMBER, YEŞİL… “gizli” ve “gizli” arasındaki farkın ne olduğu ve “gizli” ile “gizli” arasındaki farkın ne olduğu konusunda endişelenmeden küresel olarak çalışan bir metafor, tüm bu karmaşık şeyler. etrafında bir sürü yasaya ihtiyacı var.

TLP'de bazı değişiklikler yapıldı.

Bu nedenle, siber güvenlik araştırması yapıyorsanız, bunların farkında olduğunuzdan emin olun.

TLP:WHITE aslında çok daha iyi olduğunu düşündüğüm bir terimle değiştirildi, çünkü beyaz modern çağda onsuz yapabileceğimiz tüm bu gereksiz kültürel imalara sahip.

Yani, TLP:WHITE yeni oldu TLP:CLEAR, ki bence bu çok daha iyi bir kelime çünkü “Bu verileri kullanmakta netsiniz” diyor ve bu niyet çok açık bir şekilde ifade ediliyor, ahem. (Üzgünüm, kelime oyununa dayanamadım.)

Ve ek bir katman daha var (bu yüzden metaforu biraz bozdu – artık *beş* renkli renkli trafik ışığı!).

denilen özel bir seviye var. TLP:AMBER+STRICTve bunun anlamı, "Bunu şirketinizde paylaşabilirsiniz."

Yani bir toplantıya davet edilebilirsiniz, belki bir siber güvenlik şirketi için çalışıyorsunuz ve bunu programcılara, belki BT ekibinize, belki de kalite güvence görevlilerinize göstermeniz gerekeceği oldukça açık, böylece araştırma yapabilirsiniz. sorun ya da düzeltmekle uğraşın.

Fakat TLP:AMBER+STRICT bunu kuruluşunuzun içinde dolaştırabilmenize rağmen, *lütfen müşterilerinize veya müşterilerinize*, hatta şirket dışındaki kişilere bilmesi gerektiğini düşündüğünüzü söylemeyin.

Başlamak için daha sıkı topluluk içinde tutun.

TLP:AMBER, daha önce olduğu gibi, "Tamam, müşterilerinize söylemeniz gerektiğini düşünüyorsanız, yapabilirsiniz" anlamına gelir.

Ve bu önemli olabilir, çünkü bazen müşterilerinizi bilgilendirmek isteyebilirsiniz, “Hey, düzeltmemiz geliyor. Düzeltme gelmeden önce bazı ihtiyati adımlar atmanız gerekecek. Ama biraz hassas olduğu için, henüz dünyaya söylememenizi isteyebilir miyiz?”

Bazen dünyaya çok erken söylemek, savunmacılardan çok dolandırıcıların işine geliyor.

Bu nedenle, bir siber güvenlik görevlisiyseniz, şunu yapmanızı öneririm: https://www.first.org/tlp

---

DOUG.  Ve yapabilirsin bunun hakkında daha fazlasını oku sitemizde çıplakgüvenlik.sophos.com.

Ve eğer başka bir ışık okuması arıyorsanız, kuantum kriptografiyi unutun… kuantum sonrası kriptografiPaul!

---

ÖRDEK.  Evet, bunu daha önce podcast'te birkaç kez konuştuk, değil mi?

Yeterince güçlü ve güvenilir bir bilgisayarın inşa edilebileceğini varsayarak bir kuantum bilgisayar fikri, belirli türdeki algoritmaların, günümüzün en son durumu üzerinden, ya karekök ayarına göre hızlandırılabileceğidir… ya da daha da kötüsü, Sorunun bugünkü ölçeğinin *logaritması*.

Başka bir deyişle, 2 almak yerine²⁵⁶ belirli bir karmaya sahip bir dosya bulmaya çalışırsa, bunu sadece (“sadece”!) 2¹²⁸ karekök olan dener.

Açıkçası çok daha hızlı.

Ancak, teorinin, bugün aldıkları zamanın *logaritmasında* kırılabileceğini söylediği, asal sayıların çarpımlarını çarpanlara ayırmayı içeren bir dizi problem var, gevşek bir şekilde konuşursak.

Yani, almak yerine, diyelim ki, 2¹²⁸ [EVRENİN MEVCUT YAŞINDAN ÇOK DAHA UZUN] çatlamak için günler, çatlamak sadece 128 gün sürebilir.

Ya da "günleri" yerine "dakikalar" veya herhangi bir şey koyabilirsiniz.

Ve ne yazık ki, bu logaritmik zaman algoritması ( Shor'un Kuantum Çarpanlara Ayırma Algoritması)… bu, teoride, günümüzün kriptografik tekniklerinden bazılarına, özellikle açık anahtar kriptografisi için kullanılanlara uygulanabilir.

Ve bu kuantum hesaplama cihazlarının önümüzdeki birkaç yıl içinde uygulanabilir hale gelmesi durumunda, belki de bu iki özel saldırı sınıfına karşı savunmasız olmayan şifreleme algoritmaları için şimdiden hazırlanmaya başlamalıyız?

Özellikle logaritma bir, çünkü potansiyel saldırıları o kadar büyük ölçüde hızlandırır ki, şu anda düşündüğümüz kriptografik anahtarlar, "Eh, kimse bunu asla çözemez", daha sonraki bir aşamada ortaya çıkabilir.

Her neyse, NIST, Ulusal Standartlar ve Teknoloji Enstitüsü ABD'de, birkaç yıldır, ortaya çıkarsa bu büyülü kuantum bilgisayarlara dirençli olacak bazı halka açık, patentsiz, iyi incelenmiş algoritmaları denemek ve standartlaştırmak için bir rekabet yürütüyor.

Ve son zamanlarda standartlaştırmaya hazır oldukları dört algoritma seçtiler.

Harika isimleri var Doug, bu yüzden onları okumalıyım: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON, ve SPHINCS+. [Gülüşmeler]

Yani başka bir şey değilse bile havalı isimleri var.

Ancak aynı zamanda NIST, “Eh, bu sadece dört algoritma. Yapacağımız şey, potansiyel ikincil adaylar olarak dört tane daha seçeceğiz ve bunlardan herhangi birinin geçip geçmeyeceğini göreceğiz.”

Yani şu anda dört standartlaştırılmış algoritma ve gelecekte standart hale gelebilecek dört algoritma var.

Veya 5 Temmuz 2022'de * dört kişi* vardı ve bunlardan biri SIKEiçin kısa tekil izogen anahtar kapsülleme.

(Singular izogenileri açıklamak için birkaç podcast'e ihtiyacımız olacak, bu yüzden zahmet etmeyeceğiz. [GÜLME])

Ancak, ne yazık ki, standart hale getirilmek için savaşma şansıyla orada asılı duran bu, en az beş yıldır kamu denetimine açık olmasına rağmen, onarılamaz bir şekilde kırılmış gibi görünüyor.

Neyse ki, standart hale gelmeden veya standart hale gelmeden hemen önce, iki Belçikalı kriptograf, “Biliyor musun? Sadece bir çekirdek kullanarak, oldukça ortalama bir CPU'da yaklaşık bir saat süren hesaplamaları kullanarak bu sorunu aşmanın bir yolunu bulduğumuzu düşünüyoruz."

---

DOUG.  Sanırım bunu standart hale getirip vahşi doğaya çıkardıktan sonra şimdi bulmak daha mı iyi?

---

ÖRDEK.  Aslında!

Sanırım zaten standartlaştırılmış algoritmalardan biri olsaydı, standardı yürürlükten kaldırmaları ve yeni bir tane bulmaları gerekirdi?

Bunun beş yıl boyunca fark edilmemesi garip görünüyor.

Ama sanırım kamu incelemesinin bütün fikri bu: Birinin ne zaman ihtiyaç duyulan çatlağa veya küçük kamaya girip algoritmanın başlangıçta düşünüldüğü kadar güçlü olmadığını kanıtlamak için kullanabilecekleri ne zaman vuracağını asla bilemezsiniz.

İyi bir hatırlatma, eğer *hiç* kendi kriptografinizi örmeyi düşündüyseniz…

---

DOUG.  [GÜLER] Yapmadım!

---

ÖRDEK.  ..Size Naked Security podcast'inde N kez “Bunu yapma!” dememize rağmen.

Bu, gerçek uzmanlar beş yıl boyunca küresel bir rekabette kamu denetimine tabi bir algoritma ortaya koysalar bile, bunun oldukça kötü olduğu ortaya çıkan kusurları ortaya çıkarmak için yeterli zaman sağlamadığının nihai hatırlatıcısı olmalıdır.

Yani, bunun için kesinlikle iyi görünmüyor SIKE algoritması.

Ve kim bilir, belki geri çekilir?

---

DOUG.  Buna dikkat edeceğiz.

Ve bu haftaki şovumuzda güneş yavaşça batarken, okuyucularımızdan birinden daha önce tartıştığımız GitHub hikayesini duymanın zamanı geldi.

soymak yazıyor:

“Yorumlarda biraz tebeşir ve peynir var ve bunu söylemekten nefret ediyorum ama tartışmanın her iki tarafını da gerçekten görebiliyorum. Tehlikeli, zahmetli, zaman kaybı ve kaynak tüketiyor mu? Evet, tabi ki öyle. Suçlu düşünen tiplerin yapacağı şey bu mu? Evet evet o. GitHub'ı veya bu konuda başka herhangi bir kod deposu sistemini kullanan herkese, internette güvenli bir şekilde seyahat etmenin sağlıklı bir sinizm ve paranoya derecesi gerektirdiğini hatırlatıyor mu? Evet. Bir sistem yöneticisi olarak, bir yanım mevcut riskin açığa çıkmasını alkışlamak istiyor. Bir grup geliştiricinin sistem yöneticisi olarak, şimdi herkesin son zamanlarda şüpheli girişler için herhangi bir çekmeyi araştırdığından emin olmam gerekiyor. ”

---

ÖRDEK.  Evet, bu yorum için teşekkürler RobB, çünkü sanırım tartışmanın her iki tarafını da görmek önemli.

Sadece "Bunun sorunu ne? Bu harika!"

Bir kişi dedi ki, “Hayır, aslında bu kalem testi iyi ve kullanışlı. Çirkin kafalarını gerçek bir saldırgandan almak yerine bunların şimdi ortaya çıkmasına sevinin.”

Ve buna yanıtım, "Eh, bu *aslında* bir saldırıdır."

Sadece biri çıktıktan sonra “Oh, hayır, hayır. Zarar verilmedi! Dürüst olmak gerekirse, yaramazlık yapmıyordum.”

Bu bahaneyi satın almak zorunda olduğunu sanmıyorum!

Ama her neyse, bu penetrasyon testi değil.

Cevabım çok basit bir şekilde şunu söylemek oldu: "Sorumlu sızma test edicileri [A]'yı yalnızca açık izin aldıktan sonra ve [B] önceden açıkça kararlaştırılan davranışsal sınırlar dahilinde hareket eder."

Sadece kendi kurallarınızı koymuyorsunuz ve bunu daha önce tartışmıştık.

Yani, başka bir yorumcunun dediği gibi, sanırım en sevdiğim yorum bu… dedi Ecurb, “Bence birisi kapı kilitlerinin gerçekte ne kadar etkisiz olduğunu göstermek için evden eve yürümeli ve camları kırmalıdır. Bu vadesi geçmiş. Biri şuna atlasın lütfen."

Ve sonra, bunun hiciv olduğunu fark etmediyseniz, millet, diyor ki, "Değil!"

---

ÖRDEK.  Bunun iyi bir hatırlatma olduğu fikrini alıyorum ve hem üretici hem de tüketici olarak GitHub kullanıcısıysanız yapabileceğiniz şeyler olduğu fikrini alıyorum.

Bunları yorumlarda ve makalede listeliyoruz.

Örneğin, tüm taahhütlerinize dijital bir imza koyun, böylece değişikliklerin sizden geldiği ve bir tür izlenebilirlik olduğu açıktır.

Ve sadece bir arama yaptınız ve doğru proje olabileceğine “göründü” diye bir şeyleri körü körüne tüketmeyin.

Evet, hepimiz bundan bir şeyler öğrenebiliriz ama bu aslında bize öğretmek sayılır mı, yoksa bu zaten öğrenmemiz gereken bir şey mi?

Bence bu * öğretme * değil.

Sadece araştırma olarak sayılacak *yeterince yüksek bir standart değil*.

---

DOUG.  Bu makale etrafında harika bir tartışma ve bunu gönderdiğiniz için teşekkürler, Rob.

İletmek istediğiniz ilginç bir hikayeniz, yorumunuz veya sorunuz varsa, podcast'te okumayı çok isteriz.

E-posta gönderebilirsiniz tips@sophos.com; yazılarımızdan herhangi birine yorum yapabilirsiniz; ya da bize sosyal medyadan ulaşabilirsiniz: @NakedSecurity.

Bugünkü programımız bu – dinlediğiniz için çok teşekkürler.

Paul Ducklin için, ben Doug Aamoth, bir dahaki sefere kadar size şunu hatırlatıyorum...

---

HER İKİSİ DE.  Güvende kalın!

[MÜZİKAL MODEM]