S3 Ep95: Slack Leak، حمله Github و رمزارز پس کوانتومی [صوت + متن]

برای پرش به هر نقطه، روی امواج صوتی زیر کلیک کنید و بکشید. شما همچنین می توانید مستقیم گوش کن در Soundcloud

دوغ.  درزهای شل، کدهای شیطون GitHub و رمزنگاری پسا کوانتومی.

همه اینها و خیلی بیشتر در پادکست Naked Security.

[مودم موزیکال]

به پادکست خوش آمدید، همه.

من داگ آموت هستم.

مثل همیشه پل داکلین با من است.

پل، امروز چطوری؟

---

اردک.  سوپر دوپر، طبق معمول، داگ!

---

دوغ.  من برای رسیدن به این هفته بسیار هیجان زده هستم تاریخچه فناوری بخش، زیرا…

... تو اونجا بودی مرد!

این هفته در 11 آگوست …

---

اردک.  وای نه!

فکر کنم پولش کم شده…

---

دوغ.  حتی لازم نیست سال را بگویم!

11 اوت 2003 - جهان متوجه کرم Blaster شد که بر سیستم‌های ویندوز 2000 و ویندوز XP تأثیر گذاشت.

Blaster که با نام‌های Lovesan و MsBlast نیز شناخته می‌شود، از یک سرریز بافر سوء استفاده کرد و شاید بیشتر برای این پیام شناخته شده است. «بیلی گیتس، چرا این امکان را می‌دهی؟ از پول درآوردن دست بردارید و نرم افزار خود را تعمیر کنید.»

چه اتفاقی افتاد، پل؟

---

اردک.  خوب، آن دوره قبل از آن بود، شاید ما امنیت را خیلی جدی گرفتیم.

و خوشبختانه، امروزه بهره برداری از این نوع باگ بسیار دشوارتر خواهد بود: این یک سرریز بافر مبتنی بر پشته بود.

و اگر درست یادم باشد، نسخه‌های سرور ویندوز از قبل با چیزی که نام دارد ساخته می‌شد حفاظت پشته.

به عبارت دیگر، اگر پشته را در داخل یک تابع سرریز کنید، قبل از اینکه تابع برگردد و با پشته خراب آسیب وارد کند، متوجه می شود که اتفاق بدی افتاده است.

بنابراین، باید برنامه متخلف را خاموش کند، اما بدافزار اجرا نمی شود.

اما این محافظت در آن زمان در نسخه های کلاینت ویندوز وجود نداشت.

و همانطور که به یاد دارم، این یکی از بدافزارهای اولیه بود که باید حدس می زد کدام نسخه از سیستم عامل را دارید.

آیا در سال 2000 هستید؟ آیا در NT هستید؟ آیا در XP هستید؟

و اگر اشتباه کرد، بخش مهمی از سیستم از کار می افتد و هشدار «سیستم شما در شرف خاموش شدن است» دریافت می کنید.

---

دوغ.  ها، من آنها را به یاد دارم!

---

اردک.  بنابراین، آن آسیب جانبی وجود داشت که برای بسیاری از مردم نشانه این بود که شما تحت تأثیر عفونت‌ها قرار می‌گیرید…

... که می تواند از خارج باشد، مثلاً اگر شما فقط یک کاربر خانگی هستید و روتر یا فایروال در خانه ندارید.

اما اگر در داخل یک شرکت بودید، محتمل‌ترین حمله از طرف شخص دیگری در داخل شرکت انجام می‌شد که بسته‌هایی را به شبکه شما پرتاب می‌کرد.

بنابراین، بسیار شبیه حمله CodeRed که ما در مورد آن صحبت کردیم، که چند سال قبل از آن بود، در پادکست اخیر، واقعاً مقیاس، حجم و سرعت این چیز بود که مشکل را ایجاد کرد.

---

دوغ.  خوب، خوب، این حدود 20 سال پیش بود.

و اگر ساعت را به پنج سال پیش برگردانیم، آن وقت است Slack شروع به نشت کرد رمزهای عبور هش شده [خنده]

---

اردک.  بله، Slack، ابزار همکاری محبوب…

... دارای ویژگی است که در آن می توانید پیوند دعوت را برای افراد دیگر ارسال کنید تا به فضای کاری شما بپیوندند.

و، تصور می‌کنید: روی دکمه‌ای کلیک می‌کنید که می‌گوید «یک پیوند ایجاد کنید»، و نوعی بسته شبکه ایجاد می‌کند که احتمالاً مقداری JSON در داخل آن وجود دارد.

اگر تا به حال دعوت‌نامه‌ای برای جلسه زوم داشته‌اید، می‌دانید که دارای یک تاریخ، یک زمان، و شخصی که شما را دعوت می‌کند، و یک URL که می‌توانید برای جلسه از آن استفاده کنید، و یک رمز عبور و همه این موارد دارد. چیزهای - داده های بسیار زیادی در آن وجود دارد.

به طور معمول، شما در داده‌های خام جستجو نمی‌کنید تا ببینید چه چیزی در آن وجود دارد - مشتری فقط می‌گوید: «هی، اینجا یک جلسه است، اینجا جزئیات است. آیا می خواهید بپذیرید / شاید / رد کنید؟

معلوم شد که وقتی این کار را با Slack انجام دادید، همانطور که می‌گویید، برای بیش از پنج سال، داده‌های اضافه‌شده در آن دعوت‌نامه داده‌های غیرمجاز بود که کاملاً به خود دعوتنامه مرتبط نبود.

بنابراین، نه یک URL، نه یک نام، نه تاریخ، نه زمان…

... اما * رمز عبور کاربر دعوت کننده * [خنده]

---

دوغ.  هوممم

---

اردک.  با تو شوخی ندارم!

---

دوغ.  به نظر بد میاد…

---

اردک.  بله، واقعاً اینطور است، اینطور نیست؟

خبر بد این است که چگونه آن را وارد آنجا کرد؟

و هنگامی که در آنجا بود، چگونه به مدت پنج سال و سه ماه از توجه دور ماند؟

در واقع، اگر به مقاله امنیت برهنه مراجعه کنید و به آن نگاه کنید URL کامل از مقاله، متوجه خواهید شد که در پایان می گوید: blahblahblah-for-three-months.

چون، وقتی برای اولین بار گزارش را خواندم، ذهنم نمی خواست آن را سال 2017 ببیند! [خنده]

از 17 آوریل تا 17 جولای بود، و بنابراین تعداد زیادی "17" در آنجا وجود داشت.

و ذهن من سال 2017 را به عنوان سال شروع خالی کرد - من آن را به اشتباه به عنوان "آوریل تا ژوئیه *این سال *" [2022] خواندم.

من فکر کردم، "وای، *سه ماه* و آنها متوجه نشدند."

و سپس اولین نظر در مورد مقاله این بود، «آهم [سرفه]. در واقع 17 آوریل *2017* بود."

وای!

اما کسی آن را در 17 ژوئیه [2022] کشف کرد، و Slack، به اعتبار خود، آن را در همان روز برطرف کرد.

مثلاً "اوه گلی، ما به چه فکر می کردیم؟"

پس این خبر بد است.

خبر خوب این است که حداقل رمزهای عبور *هش شده* بود.

و آنها نه تنها هش شدند، بلکه *سالت شدند*، جایی که شما داده‌های تصادفی انتخابی منحصر به فرد هر کاربر را با رمز عبور ترکیب می‌کنید.

ایده این دو چیز است.

یکی، اگر دو نفر رمز عبور یکسانی را انتخاب کنند، هش یکسانی دریافت نمی کنند، بنابراین نمی توانید با نگاه کردن به پایگاه داده هش، استنباط کنید.

و دوم، شما نمی توانید یک فرهنگ لغت از هش های شناخته شده را برای ورودی های شناخته شده از قبل محاسبه کنید، زیرا باید یک فرهنگ لغت جداگانه برای هر رمز عبور *برای هر salt* ایجاد کنید.

بنابراین شکستن رمزهای عبور هش شده یک تمرین بی اهمیت نیست.

با این اوصاف، کل ایده این است که آنها قرار نیست یک موضوع ثبت عمومی باشند.

در صورت نشت آنها هش و نمک زده می شوند، نه برای اینکه نشت کنند.

بنابراین، تخم مرغ روی صورت Slack!

Slack می گوید که از هر 200 کاربر یک نفر یا 0.5٪ تحت تأثیر قرار گرفتند.

اما اگر شما یک کاربر Slack هستید، فرض می‌کنم اگر آنها متوجه نشوند که رمزهای عبور هش شده را به مدت پنج سال درز کرده‌اند، ممکن است لیست افرادی را که تحت تأثیر قرار گرفته‌اند کاملاً برشمارند.

بنابراین، به هر حال بروید و رمز عبور خود را تغییر دهید ... شما نیز ممکن است.

---

دوغ.  خوب، ما همچنین می گوییم: اگر از یک مدیر رمز عبور استفاده نمی کنید، در نظر بگیرید. و اگر می توانید 2FA را روشن کنید.

---

اردک.  فکر کردم دوست داری، داگ.

---

دوغ.  بله، من!

و سپس، اگر شما Slack یا شرکتی مانند آن هستید، a را انتخاب کنید الگوریتم نمک هش و کشش معتبر زمانی که خودتان پسوردها را مدیریت می کنید.

---

اردک.  بله.

نکته مهم در پاسخ Slack، و چیزی که من فکر می‌کردم کم است، این است که آنها فقط گفتند: «نگران نباش، نه تنها پسوردها را هش کردیم، بلکه آنها را هم نمک زدیم.»

توصیه من این است که اگر در چنین شکافی گرفتار شدید، باید الگوریتم یا فرآیندی را که برای نمک زدن و هش کردن استفاده کرده‌اید، و همچنین در حالت ایده‌آل آنچه نامیده می‌شود، اعلام کنید. کشش، جایی است که شما فقط یک بار رمز عبور نمک را هش نمی کنید، بلکه ممکن است آن را 100,000 بار هش کنید تا هر نوع حمله لغت نامه یا brute force را کاهش دهید.

و اگر بگویید از چه الگوریتمی و با چه پارامترهایی استفاده می کنید.. مثلاً PBKDF2, bcrypt, scrypt, Argon2 - اینها شناخته شده ترین الگوریتم های رمز عبور "salt-hash-stretch" هستند.

اگر واقعاً بیان می‌کنید که از چه الگوریتمی استفاده می‌کنید، آنگاه: [A] شما بازتر رفتار می‌کنید، و [B] به قربانیان احتمالی مشکل این فرصت را می‌دهید که خودشان ارزیابی کنند که فکر می‌کنند این ممکن است چقدر خطرناک بوده است. .

و این نوع باز بودن در واقع می تواند کمک زیادی کند.

Slack این کار را نکرد.

آنها فقط گفتند: "اوه، آنها نمک زدند و هش کردند."

اما چیزی که نمی دانیم این است که آیا آنها دو بایت نمک ریختند و سپس یک بار با SHA-1 آنها را هش کردند؟

... یا چیزی کمی مقاوم تر در برابر ترک خوردگی داشتند؟

---

دوغ.  با چسبیدن به موضوع چیزهای بد، ما متوجه روندی هستیم که در آن مردم در حال توسعه هستند تزریق چیزهای بد به گیت هاب، فقط برای اینکه ببینیم چه اتفاقی می افتد، در معرض خطر…

... ما یکی دیگر از آن داستان ها را داریم.

---

اردک.  بله، کسی که اکنون ظاهراً در توییتر آمده است و گفته است: «بچه ها نگران نباشید، هیچ آسیبی وارد نشده است. فقط برای تحقیق بود من می‌خواهم گزارشی بنویسم، از Blue Alert متمایز شوم.»

آنها به معنای واقعی کلمه هزاران پروژه جعلی GitHub را بر اساس کپی کردن کدهای قانونی موجود، درج عمدی برخی از دستورات بدافزار در آنجا ایجاد کردند، مانند "برای دستورالعمل های بیشتر با خانه تماس بگیرید" و "تعبیر بدنه پاسخ به عنوان کد درب پشتی برای اجرا"، و به زودی.

بنابراین، مواردی که اگر یکی از این بسته‌ها را نصب کنید، واقعاً می‌تواند آسیب برساند.

گذاشتن اسامی قانونی به آنها…

... وام گرفتن، ظاهراً تاریخچه تعهد یک پروژه واقعی، به طوری که اگر فقط با این جمله ظاهر می شد، چیز بسیار قانونی تر از آن چیزی به نظر می رسید که در غیر این صورت ممکن بود انتظارش را داشته باشید: «هی، این فایل را دانلود کنید. میدونی که میخوای!»

واقعا؟! پژوهش؟؟ ما قبلاً این را نمی دانستیم؟!!؟

حالا، می‌توانید استدلال کنید، «خب، مایکروسافت، صاحب GitHub، چه کاری انجام می‌دهند که آپلود این نوع مطالب را برای مردم آسان می‌کند؟»

و حقیقتی در آن وجود دارد.

شاید در وهله اول بتوانند کار بهتری برای جلوگیری از بدافزار انجام دهند.

اما گفتن "اوه، همه اینها تقصیر مایکروسافت است."

به نظر من حتی بدتر است که بگوییم: «بله، این تحقیق واقعی است. این واقعا مهم است؛ ما باید به مردم یادآوری کنیم که ممکن است این اتفاق بیفتد."

خوب، [A] ما قبلاً می دانیم که، بسیار متشکرم، زیرا افراد زیادی قبلاً این کار را انجام داده اند. ما پیام را با صدای بلند و واضح دریافت کردیم.

و [B] این *پژوهشی* نیست.

این به عمد سعی می کند مردم را فریب دهد تا کدی را دانلود کنند که به مهاجم بالقوه کنترل از راه دور می دهد، در ازای توانایی نوشتن گزارش.

این برای من بیشتر شبیه یک "بهانه بزرگ" به نظر می رسد تا یک انگیزه مشروع برای تحقیق.

و بنابراین توصیه من این است که اگر فکر می کنید این *یک* تحقیق است، و اگر مصمم هستید که چنین کاری را دوباره انجام دهید، *منتظر همدردی زیادی نباشید* اگر گرفتار شدید.

---

دوغ.  بسیار خوب - ما به این موضوع باز خواهیم گشت و خواننده در پایان نمایش نظرات خود را بیان می‌کند، پس در این مورد بمانید.

اما ابتدا اجازه دهید در مورد آن صحبت کنیم چراغ راهنماو چه ارتباطی با امنیت سایبری دارند.

---

اردک.  آهان، بله! [خنده]

خوب، چیزی به نام TLP وجود دارد پروتکل چراغ راهنمایی.

و TLP همان چیزی است که ممکن است آن را «پروتکل تحقیقاتی امنیت سایبری انسانی» بنامید که به شما کمک می‌کند اسنادی را که برای افراد دیگر ارسال می‌کنید برچسب‌گذاری کنید، تا به آنها اشاره‌ای از آنچه شما امیدوارید انجام دهند (و مهم‌تر از آن، آنچه شما امیدوارید انجام دهند * نه*) با داده ها انجام دهید.

به ویژه، آنها قرار است تا چه حد آن را مجدداً توزیع کنند؟

آیا این موضوع آنقدر مهم است که بتوانید آن را به دنیا اعلام کنید؟

یا این به طور بالقوه خطرناک است، یا به طور بالقوه شامل مواردی است که ما نمی‌خواهیم هنوز عمومی شوند... پس آن را برای خود نگه دارید؟

و شروع شد با: TLP:RED، که به معنای "آن را برای خود نگه دارید" بود. TLP:AMBER، به این معنی است که "شما می توانید آن را در داخل شرکت خود یا مشتریانی که فکر می کنید نیاز فوری به دانستن این موضوع دارند" منتشر کنید. TLP:GREEN، که به این معنی بود، "خوب، شما می توانید اجازه دهید این به طور گسترده در جامعه امنیت سایبری منتشر شود."

و TLP:WHITE، به این معنی بود که "شما می توانید به هر کسی بگویید."

بسیار مفید، بسیار ساده: قرمز، کهربایی، سبز... استعاره ای که در سطح جهانی کار می کند، بدون نگرانی در مورد اینکه تفاوت بین "محرمانه" و "محرمانه" چیست و تفاوت بین "محرمانه" و "طبقه بندی شده" چیست، همه چیزهای پیچیده ای که نیاز به قوانین زیادی پیرامون آن دارد.

خوب، TLP به تازگی تغییراتی داشته است.

بنابراین، اگر اهل تحقیق در مورد امنیت سایبری هستید، مطمئن شوید که از آنها آگاه هستید.

TLP:WHITE به چیزی که من در واقع اصطلاح بسیار بهتری می دانم، تغییر یافته است، زیرا سفید همه این مضامین فرهنگی غیرضروری را دارد که در عصر مدرن می‌توانیم بدون آنها کار کنیم.

پس TLP:WHITE تازه تبدیل شده است TLP:CLEAR، که به نظر من کلمه بسیار بهتری است زیرا می گوید: "تو واضح است که از این داده ها استفاده می کنی" و این قصد بسیار واضح بیان شده است. (ببخشید، من نتوانستم در برابر جناس مقاومت کنم.)

و یک لایه اضافی وجود دارد (بنابراین استعاره را کمی خراب کرده است - اکنون یک چراغ راهنمایی رنگی *پنج* رنگ است!).

یک سطح خاص به نام وجود دارد TLP:AMBER+STRICTو معنی آن این است که "شما می توانید این را در شرکت خود به اشتراک بگذارید."

بنابراین ممکن است شما به یک جلسه دعوت شوید، شاید برای یک شرکت امنیت سایبری کار می کنید، و کاملاً واضح است که باید این را به برنامه نویسان، شاید به تیم فناوری اطلاعات خود، شاید به افراد تضمین کیفیت خود نشان دهید، تا بتوانید در مورد آن تحقیق کنید. مشکل یا مقابله با رفع آن.

اما TLP:AMBER+STRICT به این معنی است که اگرچه می‌توانید آن را در داخل سازمان خود منتشر کنید، *لطفاً به مشتریان یا مشتریان خود*، یا حتی افرادی خارج از شرکت که فکر می‌کنید ممکن است نیاز به دانستن دارند، نگوئید.

برای شروع آن را در جامعه فشرده تر نگه دارید.

TLP:AMBERمانند قبل، به این معنی است که "خوب، اگر احساس می کنید باید به مشتریان خود بگویید، می توانید."

و این می تواند مهم باشد، زیرا گاهی اوقات ممکن است بخواهید به مشتریان خود اطلاع دهید، "هی، ما راه حلی در پیش داریم. قبل از رسیدن تعمیر، باید اقدامات احتیاطی را انجام دهید. اما چون به نوعی حساس است، ممکن است از شما بخواهیم که هنوز به دنیا نگویید؟

گاهی اوقات، زود گفتن به دنیا در واقع بیشتر به نفع کلاهبرداران است تا به نفع مدافعان.

بنابراین، اگر شما یک پاسخگوی امنیت سایبری هستید، پیشنهاد می کنم بروید: https://www.first.org/tlp

---

دوغ.  و تو می توانی در مورد آن بیشتر بخوانید در سایت ما ، nadsecurity.sophos.com.

و اگر به دنبال خواندن نور دیگری هستید، رمزنگاری کوانتومی را فراموش کنید... ما در حال حرکت به سمت آن هستیم رمزنگاری پس کوانتومی، پل!

---

اردک.  بله، قبلاً چند بار در پادکست در این مورد صحبت کرده ایم، اینطور نیست؟

ایده یک کامپیوتر کوانتومی، با فرض اینکه بتوان به اندازه کافی قدرتمند و قابل اعتماد ساخته شود، این است که انواع خاصی از الگوریتم‌ها را می‌توان در سطح پیشرفته امروزی سرعت بخشید، یا به اندازه جذر... یا حتی بدتر، *لگاریتم* مقیاس مسئله امروز.

به عبارت دیگر، به جای گرفتن 2²⁵⁶ سعی می کند یک فایل با یک هش خاص پیدا کند، ممکن است بتوانید آن را فقط در ("فقط"!) انجام دهید 2¹²⁸ تلاش می کند که جذر آن است.

واضحه خیلی سریعتر

اما یک دسته کامل از مشکلات مربوط به فاکتورسازی محصولات اعداد اول وجود دارد که این نظریه می‌گوید که می‌توان آن‌ها را در *لگاریتم* زمانی که امروز می‌گذراند، به زبان ساده شکست داد.

بنابراین، به جای گرفتن، مثلاً 2¹²⁸ چند روز برای شکستن [به مراتب طولانی تر از سن کنونی جهان]، ممکن است تنها 128 روز طول بکشد تا شکسته شود.

یا می توانید «روزها» را با «دقیقه» یا هر چیز دیگری جایگزین کنید.

و متاسفانه، آن الگوریتم زمان لگاریتمی (نامیده می شود الگوریتم فاکتورسازی کوانتومی شور)... که در تئوری می تواند برای برخی از تکنیک های رمزنگاری امروزی، به ویژه آنهایی که برای رمزنگاری کلید عمومی استفاده می شوند، اعمال شود.

و، فقط در صورتی که این دستگاه‌های محاسباتی کوانتومی در چند سال آینده امکان‌پذیر شوند، شاید باید از هم‌اکنون آماده‌سازی برای الگوریتم‌های رمزگذاری که در برابر این دو دسته خاص از حمله آسیب‌پذیر نیستند، شروع کنیم؟

به خصوص لگاریتمی، زیرا حملات بالقوه را چنان سرعت می‌بخشد که کلیدهای رمزنگاری که در حال حاضر فکر می‌کنیم "خب، هیچ کس هرگز آن را نمی‌فهمد" ممکن است در مراحل بعدی قابل نمایش شوند.

به هر حال، NIST، موسسه ی ملی استانداردها و تکنولوژی در ایالات متحده آمریکا، چندین سال است که مسابقه‌ای را برای استانداردسازی برخی از الگوریتم‌های عمومی، بدون ثبت اختراع و به خوبی بررسی شده برگزار می‌کند که در صورت وجود، در برابر این رایانه‌های کوانتومی جادویی مقاوم خواهند بود.

و اخیراً آنها چهار الگوریتم را انتخاب کردند که اکنون آماده استانداردسازی آنها هستند.

آنها نام های جالبی دارند، داگ، بنابراین باید آنها را بخوانم: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONو SPHINCS+. [خنده]

بنابراین آنها نام های جالبی دارند، اگر چیز دیگری نباشد.

اما، در همان زمان، NIST متوجه شد: «خب، این فقط چهار الگوریتم است. کاری که ما انجام خواهیم داد این است که چهار نفر دیگر را به عنوان کاندیدای ثانویه بالقوه انتخاب خواهیم کرد و خواهیم دید که آیا هر یک از آنها نیز باید از آن عبور کنند."

بنابراین اکنون چهار الگوریتم استاندارد شده و چهار الگوریتم وجود دارد که ممکن است در آینده استاندارد شوند.

یا در 5 ژوئیه 2022 چهار نفر *بودند، و یکی از آنها بود SIKE، کوتاه برای کپسوله سازی کلید ایزووژنی فوق منفرد.

(ما به چندین پادکست برای توضیح ایزوژنی های فوق منفرد نیاز داریم، بنابراین ما را خسته نخواهیم کرد. [خنده])

اما، متأسفانه، این یکی، که در آنجا آویزان بود و شانس مبارزه برای استاندارد شدن داشت، به نظر می رسد که به طور غیرقابل جبرانی شکسته شده است، علیرغم اینکه حداقل پنج سال از قبل برای بررسی عمومی باز بود.

بنابراین، خوشبختانه، درست قبل از اینکه استاندارد شود یا استاندارد شود، دو رمزنگار بلژیکی متوجه شدند: «می‌دانی چیست؟ ما فکر می‌کنیم که با استفاده از محاسباتی که در یک CPU نسبتاً متوسط، فقط با استفاده از یک هسته، حدود یک ساعت طول می‌کشد، راهی برای حل این مشکل پیدا کرده‌ایم.

---

دوغ.  من حدس می‌زنم بهتر است که اکنون آن را بفهمیم تا بعد از استاندارد کردن آن و بیرون آوردن آن در طبیعت؟

---

اردک.  در واقع!

حدس می‌زنم اگر یکی از الگوریتم‌هایی بود که قبلاً استاندارد شده بود، آنها باید استاندارد را لغو می‌کردند و الگوریتم جدیدی ارائه می‌کردند؟

عجیب به نظر می رسد که این موضوع به مدت پنج سال مورد توجه قرار نگرفت.

اما من حدس می‌زنم این کل ایده بررسی عمومی است: شما هرگز نمی‌دانید چه زمانی ممکن است کسی به شکاف مورد نیاز ضربه بزند، یا گوه کوچکی که می‌تواند از آن برای شکستن و اثبات اینکه الگوریتم به اندازه‌ای که در ابتدا تصور می‌شد قوی نیست، استفاده کند.

یک یادآوری خوب که اگر *تا به حال* به فکر بافتن رمزنگاری خود افتاده اید…

---

دوغ.  [می خندد] نه!

---

اردک.  .. علیرغم اینکه N بار در پادکست Naked Security به شما گفته ایم، "این کار را نکن!"

این باید یادآوری نهایی باشد که، حتی زمانی که کارشناسان واقعی الگوریتمی را ارائه می‌کنند که در یک رقابت جهانی به مدت پنج سال در معرض بررسی عمومی قرار دارد، باز هم لزوماً زمان کافی برای افشای نقص‌هایی که بسیار بد هستند را فراهم نمی‌کند.

بنابراین، مطمئناً برای این کار خوب به نظر نمی رسد SIKE الگوریتم

و چه کسی می داند، شاید پس گرفته شود؟

---

دوغ.  ما مراقب آن خواهیم بود.

و همانطور که خورشید به آرامی در برنامه ما برای این هفته غروب می کند، وقت آن است که از یکی از خوانندگان خود در مورد داستان GitHub که قبلاً صحبت کردیم بشنویم.

غارت می نویسد::

"در نظرات مقداری گچ و پنیر وجود دارد، و من از گفتن آن متنفرم، اما من واقعاً می توانم هر دو طرف بحث را ببینم. آیا خطرناک، دردسرساز، اتلاف وقت و مصرف منابع است؟ بله، حتما اینطور هست. آیا این همان کاری است که افراد جنایتکار انجام می دهند؟ بله، بله همینطور است. آیا برای هر کسی که از GitHub یا هر سیستم مخزن کد دیگری استفاده می کند، یادآوری می کند که سفر ایمن به اینترنت نیاز به درجه ای از بدبینی و پارانویا دارد؟ آره. به عنوان یک مدیر سیستم، بخشی از من می‌خواهد در معرض خطر قرار گرفتن در دست تحسین باشد. من به‌عنوان مدیر سیستم برای دسته‌ای از توسعه‌دهندگان، اکنون باید مطمئن شوم که همه اخیراً هرگونه درخواستی را برای ورودی‌های مشکوک بررسی کرده‌اند.»

---

اردک.  بله، از شما متشکرم، راب، برای آن نظر، زیرا حدس می‌زنم دیدن هر دو طرف بحث مهم است.

نظر دهندگانی بودند که فقط می گفتند: "مشکل این چیست؟ این عالی است!"

یک نفر گفت "نه، در واقع، این تست قلم خوب و مفید است. خوشحال باشید که اینها به جای اینکه سر زشت خود را از یک مهاجم واقعی بالا ببرند، اکنون افشا می شوند."

و پاسخ من به آن این است که "خب، این * در واقع یک حمله است."

فقط یک نفر بعد از آن بیرون آمده است و می گوید: «اوه، نه، نه. هیچ آسیبی در کار نیست! راستش من شیطون نبودم.»

من فکر نمی کنم شما مجبور به خرید آن بهانه باشید!

اما به هر حال، این تست نفوذ نیست.

پاسخ من این بود که خیلی ساده بگویم: آزمایش‌کنندگان نفوذ مسئول فقط پس از دریافت مجوز صریح، و [B] در محدوده‌های رفتاری که از قبل صریحاً توافق شده‌اند، [A] عمل می‌کنند.»

شما فقط قوانین خود را تنظیم نمی کنید، و ما قبلاً در این مورد بحث کرده ایم.

بنابراین، همانطور که یک نظر دهنده دیگر گفت، که فکر می کنم نظر مورد علاقه من است… Ecurb گفت, "من فکر می کنم کسی باید خانه به خانه راه برود و پنجره ها را بشکند تا نشان دهد که قفل درها واقعاً چقدر ناکارآمد هستند. این سررسید است. لطفاً یکی به این موضوع بپرد.»

و بعد، فقط اگر متوجه نشدید که این طنز بود، او می گوید: "نه!"

---

اردک.  من این ایده را می‌دانم که یادآوری خوبی است، و این ایده را دریافت می‌کنم که اگر کاربر GitHub هستید، هم به‌عنوان تولیدکننده و هم به‌عنوان مصرف‌کننده، کارهایی وجود دارد که می‌توانید انجام دهید.

ما آنها را در نظرات و در مقاله فهرست می کنیم.

به عنوان مثال، روی تمام تعهدات خود یک امضای دیجیتال قرار دهید تا مشخص شود که تغییرات از طرف شما انجام شده است و نوعی قابلیت ردیابی وجود دارد.

و فقط کورکورانه چیزها را مصرف نکنید زیرا جستجو کرده اید و "به نظر می رسد" ممکن است پروژه مناسبی باشد.

بله، همه ما می‌توانیم از این موضوع یاد بگیریم، اما آیا این واقعاً به عنوان آموزش به ما محسوب می‌شود یا این فقط چیزی است که به هر حال باید یاد بگیریم؟

من فکر می کنم این آموزش *نه* است.

این فقط *از استاندارد کافی برخوردار نیست* که بتوان آن را به عنوان تحقیق به حساب آورد.

---

دوغ.  بحث عالی در مورد این مقاله، و از ارسال آن متشکرم، راب.

اگر داستان، نظر یا سوال جالبی دارید که می‌خواهید ارسال کنید، مایلیم آن را در پادکست بخوانید.

می توانید ایمیل بزنید tips@sophos.com; شما می توانید در مورد هر یک از مقالات ما نظر دهید. یا می توانید ما را در شبکه های اجتماعی معرفی کنید: @NakedSecurity.

این برنامه امروز ماست - خیلی ممنون که گوش دادید.

برای پل داکلین، من داگ آموت را به شما یادآوری می کنم، تا دفعه بعد، به…

---

هر دو.  ایمن بمان

[مودم موزیکال]