S3 Ep95: דליפה רפה, הסתערות Github והקריפטו פוסט-קוונטי [אודיו + טקסט]

לחץ וגרור על גלי הקול למטה כדי לדלג לכל נקודה. אתה יכול גם להקשיב ישירות בסאונדקלאוד.

DOUG.  דליפות רפויות, קוד GitHub שובב והצפנה פוסט-קוונטית.

כל זה, ועוד הרבה יותר, בפודקאסט הביטחון העירום.

[מודם מוזיקלי]

ברוכים הבאים לפודקאסט, כולם.

אני דאג אמות'.

איתי, כמו תמיד, פול דאקלין.

פול, מה שלומך היום?

---

ברווז.  סופר-דופר, כרגיל, דאג!

---

DOUG.  אני סופר-דופר נרגש להגיע לשבוע הזה היסטוריה טכנולוגית קטע, כי…

...היית שם, בנאדם!

השבוע, ב-11 באוגוסט…

---

ברווז.  אוי לא!

אני חושב שהאגורה פשוט ירדה...

---

DOUG.  אני אפילו לא צריך להגיד את השנה!

11 באוגוסט 2003 - העולם שם לב לתולעת Blaster, המשפיעה על מערכות Windows 2000 ו-Windows XP.

Blaster, הידועה גם בשם Lovesan ו-MsBlast, ניצלה הצפת חיץ ואולי ידועה בעיקר בזכות ההודעה, "בילי גייטס, למה אתה מאפשר את זה? תפסיק להרוויח כסף ותתקן את התוכנה שלך."

מה קרה, פול?

---

ברווז.  ובכן, זה היה התקופה שלפני, אולי, לקחנו את האבטחה די ברצינות.

ולמרבה המזל, סוג כזה של באג יהיה הרבה הרבה יותר קשה לניצול בימים אלה: זה היה הצפת חיץ מבוסס מחסנית.

ואם אני זוכר נכון, גרסאות השרת של Windows כבר נבנו עם מה שנקרא הגנת מחסנית.

במילים אחרות, אם תציף את המחסנית בתוך פונקציה, אז לפני שהפונקציה תחזור ותעשה את הנזק עם המחסנית הפגומה, היא תזהה שמשהו רע קרה.

אז זה צריך לכבות את התוכנית הפוגעת, אבל התוכנה הזדונית לא מצליחה לפעול.

אבל ההגנה הזו לא הייתה בגירסאות הלקוח של Windows באותה תקופה.

וכפי שאני זוכר, זו הייתה אחת מאותן תוכנות זדוניות מוקדמות שהיו צריכים לנחש איזו גרסה של מערכת ההפעלה הייתה לך.

אתה ב-2000? אתה ב-NT? אתה ב-XP?

ואם הוא טעה, אז חלק חשוב מהמערכת יקרוס, ותקבל את האזהרה "המערכת שלך עומדת להיסגר".

---

DOUG.  הא, אני זוכר את אלה!

---

ברווז.  אז, היה הנזק הנלווה הזה שהיה, עבור אנשים רבים, הסימן לכך שאתה מקבל פטיש מזיהומים...

... מה שיכול להיות מבחוץ, כמו אם היית רק משתמש ביתי ואין לך ראוטר או חומת אש בבית.

אבל אם היית בתוך חברה, סביר להניח שההתקפה תגיע ממישהו אחר בחברה, שפולט מנות ברשת שלך.

אז, בדומה למתקפת CodeRed עליה דיברנו, שהייתה כמה שנים לפני כן, בפודקאסט האחרון, זה היה באמת קנה המידה, הנפח והמהירות של הדבר הזה שהיו הבעיה.

---

DOUG.  בסדר, ובכן, זה היה לפני 20 שנה בערך.

ואם נחזיר את השעון אחורה ללפני חמש שנים, זה הזמן רפיון התחיל לדלוף סיסמאות גיבוב. [צחוק]

---

ברווז.  כן, Slack, כלי שיתוף הפעולה הפופולרי...

...יש לו תכונה שבה אתה יכול לשלוח קישור הזמנה לאנשים אחרים להצטרף לסביבת העבודה שלך.

ואתה מתאר לעצמך: אתה לוחץ על כפתור שאומר "צור קישור", וזה יוצר איזושהי חבילת רשת שכנראה יש בתוכה איזה JSON.

אם אי פעם הייתה לך הזמנה לפגישה זום, תדע שיש לה תאריך ושעה, והאדם שמזמין אותך, וכתובת אתר שתוכל להשתמש בה לפגישה, וקוד גישה, וכל זה דברים - יש בו די הרבה נתונים.

בדרך כלל, אתה לא חופר בנתונים הגולמיים כדי לראות מה יש שם - הלקוח פשוט אומר, "היי, הנה פגישה, הנה הפרטים. האם אתה רוצה לקבל / אולי / לדחות?"

התברר שכשעשית את זה עם סלאק, כמו שאתה אומר, במשך יותר מחמש שנים, ארוז בהזמנה הזו היו נתונים מיותרים שלא לגמרי רלוונטיים להזמנה עצמה.

אז, לא כתובת אתר, לא שם, לא תאריך, לא שעה...

...אבל *ה-hash של סיסמת המשתמש המזמין* [צחוק]

---

DOUG.  המממממ.

---

ברווז.  אני ילד אתה לא!

---

DOUG.  זה נשמע רע…

---

ברווז.  כן, זה באמת קורה, לא?

החדשות הרעות הן, איך לעזאזל זה נכנס לשם?

וברגע שזה היה שם, איך לעזאזל הוא התחמק מהודעה במשך חמש שנים ושלושה חודשים?

למעשה, אם תבקר במאמר על אבטחה עירומה ותסתכל על כתובת URL מלאה של המאמר, תשים לב שכתוב בסוף, blahblahblah-for-three-months.

כי כשקראתי לראשונה את הדו"ח, המוח שלי לא רצה לראות בו 2017! [צחוק]

זה היה 17 באפריל עד 17 ביולי, ולכן היו שם הרבה "17".

והמוח שלי חיסל את 2017 כשנת ההתחלה - קראתי אותה לא נכון כ"אפריל עד יולי *של השנה*" [2022].

חשבתי, "וואו, *שלושה חודשים* והם לא שמו לב."

ואז התגובה הראשונה על המאמר הייתה, "אהמ [שיעול]. זה היה למעשה 17 באפריל *2017*."

וואו!

אבל מישהו הבין את זה ב-17 ביולי [2022], וסלאק, לזכותו, תיקן את זה באותו היום.

כמו, "אוי, גולי, מה חשבנו?!"

אז אלו החדשות הרעות.

החדשות הטובות הן שלפחות מדובר בסיסמאות *מאשש*.

והם לא היו רק גיבוב, הם היו *מלוחים*, וזה המקום שבו אתה מערבב נתונים אקראיים שנבחרו באופן ייחודי לכל משתמש עם הסיסמה.

הרעיון של זה הוא כפול.

האחת, אם שני אנשים בוחרים באותה סיסמה, הם לא מקבלים את אותו ה-hash, כך שלא תוכל להסיק מסקנות כלשהן על ידי עיון במסד הנתונים של ה-hash.

ושניים, אתה לא יכול לחשב מראש מילון של hashes ידוע עבור קלט ידוע, כי אתה צריך ליצור מילון נפרד עבור כל סיסמה *עבור כל מלח*.

אז זה לא תרגיל טריוויאלי לפצח סיסמאות גיבובות.

אחרי שאמרתי את זה, כל הרעיון הוא שהם לא אמורים להיות עניין של תיעוד ציבורי.

הם גובבים ומומלחים *למקרה* שהם דולפים, לא *על מנת שיוכלו* לדלוף.

אז, ביצה על פניו של סלאק!

סלאק אומר שכאחד מכל 200 משתמשים, או 0.5%, הושפעו.

אבל אם אתה משתמש Slack, הייתי מניח שאם הם לא היו מבינים שהם מדליפים סיסמאות גיבוב במשך חמש שנים, אולי הם גם לא ממש מנו את רשימת האנשים שנפגעו לחלוטין.

אז, לך ותשנה את הסיסמה שלך בכל מקרה... אתה יכול גם כן.

---

DOUG.  בסדר, אנחנו גם אומרים: אם אינך משתמש במנהל סיסמאות, שקול לקבל אחד; והפעל את 2FA אם אתה יכול.

---

ברווז.  חשבתי שתאהב את זה, דאג.

---

DOUG.  כן אני כן!

ואז, אם אתה Slack או חברה כמוה, בחר א אלגוריתם מלח-hash-and-strech מכובד בעת טיפול בסיסמאות בעצמך.

---

ברווז.  כן.

העניין הגדול בתגובה של סלאק, והדבר שחשבתי שחסר, הוא שהם פשוט אמרו, "אל תדאג, לא רק עשינו גיבוב של הסיסמאות, גם המלחנו אותן."

העצה שלי היא שאם אתה נתפס בפרצה כזו, אז אתה צריך להיות מוכן להכריז על האלגוריתם או התהליך שבו השתמשת להמלחה וגיבוב, ובאופן אידיאלי גם מה שנקרא מתיחה, וזה המקום שבו אתה לא רק גיבוב את הסיסמה המלוחה פעם אחת, אלא אולי אתה מקבץ אותה 100,000 פעמים כדי להאט כל סוג של מילון או מתקפת כוח גס.

ואם תציין באיזה אלגוריתם אתה משתמש ועם אילו פרמטרים.. למשל, PBKDF2, bcrypt, scrypt, Argon2 - אלו הם האלגוריתמים המוכרים ביותר של סיסמאות "מלח-hash-stretch" בחוץ.

אם אתה באמת מציין באיזה אלגוריתם אתה משתמש, אז: [A] אתה פתוח יותר, ו-[B] אתה נותן לקורבנות פוטנציאליים של הבעיה הזדמנות להעריך בעצמם עד כמה הם חושבים שזה היה מסוכן .

ופתיחות כזו יכולה לעזור מאוד.

סלאק לא עשה את זה.

הם פשוט אמרו, "הו, הם הומלחו ומחטפים."

אבל מה שאנחנו לא יודעים זה, האם הם הכניסו שני בתים של מלח ואז גיבשו אותם פעם אחת עם SHA-1...

...או שהיה להם משהו קצת יותר עמיד בפני סדוק?

---

DOUG.  אם נצמד לנושא הדברים הרעים, אנו מבחינים במגמה מתפתחת בה אנשים נמצאים הזרקת דברים רעים לתוך GitHub, רק כדי לראות מה קורה, חשיפת סיכונים...

...יש לנו עוד אחד מהסיפורים האלה.

---

ברווז.  כן, מישהו שעכשיו לכאורה יצא לטוויטר ואמר, "אל תדאגו חברים, לא נגרם נזק. זה היה רק ​​למחקר. אני הולך לכתוב דו"ח, לבלוט מ-Blue Alert".

הם יצרו ממש אלפי פרויקטים מזויפים של GitHub, המבוססים על העתקת קוד חוקי קיים, הכנסת פקודות תוכנה זדוניות בכוונה לשם, כגון "התקשר הביתה להוראות נוספות", ו"פרש את גוף התשובה כקוד דלת אחורית לביצוע", ו בקרוב.

אז, דברים שבאמת עלולים להזיק אם תתקין אחת מהחבילות האלה.

נותן להם שמות בעלי מראה חוקי...

... בהשאלה, ככל הנראה, את היסטוריית ההתחייבויות של פרויקט אמיתי, כך שהדבר נראה הרבה יותר לגיטימי ממה שהייתם יכולים לצפות אם הוא רק הופיע עם, "היי, הורד את הקובץ הזה. את יודעת שאת רוצה!"

בֶּאֱמֶת?! מחקר?? לא ידענו את זה כבר?!!?

עכשיו, אתה יכול להתווכח, "ובכן, מיקרוסופט, מי הבעלים של GitHub, מה הם עושים כדי שזה כל כך קל לאנשים להעלות דברים מהסוג הזה?"

ויש בזה קצת אמת.

אולי הם יכולים לעשות עבודה טובה יותר במניעת תוכנות זדוניות מלכתחילה.

אבל זה קצת מוגזם לומר, "אה, הכל באשמת מיקרוסופט."

זה אפילו יותר גרוע לדעתי, לומר, "כן, זה מחקר אמיתי; זה באמת חשוב; אנחנו חייבים להזכיר לאנשים שזה עלול לקרות."

ובכן, [א] אנחנו כבר יודעים את זה, תודה רבה, כי המון אנשים עשו זאת בעבר; קיבלנו את המסר חזק וברור.

ו[ב] זה *לא* מחקר.

זה מנסה בכוונה להערים על אנשים להוריד קוד שנותן לתוקף פוטנציאלי שלט רחוק, בתמורה ליכולת לכתוב דוח.

זה נשמע לי יותר כמו "תירוץ שמן גדול" מאשר מניע לגיטימי למחקר.

ולכן ההמלצה שלי היא, אם אתה חושב שזה *מחקר, ואם אתה נחוש לעשות משהו כזה שוב, *אל תצפה להרבה אהדה* אם תיתפס.

---

DOUG.  בסדר - נחזור לזה והקורא יגיב בסוף התוכנית, אז תישאר.

אבל קודם כל, בואו נדבר על רמזורים, ומה יש להם לעשות עם אבטחת סייבר.

---

ברווז.  אההה, כן! [לִצְחוֹק]

ובכן, יש דבר שנקרא TLP, ה פרוטוקול רמזור.

וה-TLP הוא מה שאתה יכול לכנות "פרוטוקול מחקר אבטחת סייבר אנושי" שעוזר לך לתייג מסמכים שאתה שולח לאנשים אחרים, כדי לתת להם רמז למה שאתה מקווה שהם יעשו (וחשוב מכך, מה אתה מקווה שהם יעשו * לא*) לעשות עם הנתונים.

בפרט, באיזו רחבה הם אמורים להפיץ אותו מחדש?

האם זה משהו כל כך חשוב שאפשר להכריז עליו לעולם?

או שזה עלול להיות מסוכן, או שזה עשוי לכלול כמה דברים שאנחנו לא רוצים שעדיין יהיו ציבוריים... אז תשמרו את זה לעצמכם?

וזה התחיל ב: TLP:RED, שפירושו, "שמור את זה לעצמך"; TLP:AMBER, שפירושו "אתה יכול להפיץ את זה בתוך החברה שלך או ללקוחות שלך שאתה חושב שאולי צריך לדעת זאת בדחיפות"; TLP:GREEN, שפירושו היה, "בסדר, אתה יכול לתת לזה להסתובב באופן נרחב בתוך קהילת אבטחת הסייבר."

ו TLP:WHITE, שפירושו, "אתה יכול לספר לכל אחד."

מאוד שימושי, מאוד פשוט: אדום, ענבר, ירוק... מטפורה שפועלת ברחבי העולם, בלי לדאוג מה ההבדל בין "סודי" ל"סודי" ומה ההבדל בין "סודי" ל"מסווג", כל הדברים המסובכים האלה צריך הרבה חוקים סביב זה.

ובכן, ה-TLP קיבל רק כמה שינויים.

לכן, אם אתה עוסק בחקר אבטחת סייבר, וודא שאתה מודע לאלו.

TLP:WHITE השתנה למה שאני מחשיב כמונח הרבה יותר טוב בעצם, כי לבן יש את כל הגוונים התרבותיים המיותרים האלה שאנחנו יכולים להסתדר בלעדיהם בעידן המודרני.

אז, TLP:WHITE זה עתה הפך להיות TLP:CLEAR, שלדעתי היא מילה הרבה יותר טובה כי היא אומרת, "ברור לך להשתמש בנתונים האלה", והכוונה הזו מוצהרת, אהמ, ברורה מאוד. (סליחה, לא יכולתי לעמוד בפני משחק המילים.)

ויש שכבה נוספת (אז זה קצת קלקל את המטאפורה - עכשיו זה רמזור בצבע *חמישה* צבעים!).

יש רמה מיוחדת שנקראת TLP:AMBER+STRICT, ומה זה אומר הוא, "אתה יכול לשתף את זה בתוך החברה שלך."

אז אולי תוזמן לפגישה, אולי אתה עובד בחברת אבטחת סייבר, וזה די ברור שתצטרך להראות את זה למתכנתים, אולי לצוות ה-IT שלך, אולי לאנשי אבטחת האיכות שלך, כדי שתוכל לעשות מחקר בנושא את הבעיה או להתמודד עם תיקון שלה.

אבל TLP:AMBER+STRICT פירושו שלמרות שאתה יכול להפיץ את זה בתוך הארגון שלך, *נא לא לספר ללקוחות שלך או ללקוחות שלך*, או אפילו לאנשים מחוץ לחברה שלדעתך יש צורך לדעת.

שמור את זה בקהילה הדוקה יותר מלכתחילה.

TLP:AMBER, כמו קודם, פירושו, "בסדר, אם אתה מרגיש שאתה צריך לספר ללקוחות שלך, אתה יכול."

וזה יכול להיות חשוב, כי לפעמים כדאי להודיע ​​ללקוחות שלך, "היי, יש לנו את התיקון. תצטרך לנקוט כמה צעדי זהירות לפני שהתיקון יגיע. אבל בגלל שזה די רגיש, אפשר לבקש שלא תספר לעולם עדיין?"

לפעמים, לספר לעולם מוקדם מדי משחק לידיים של הנוכלים יותר מאשר זה משחק לידיים של המגינים.

אז, אם אתה מגיב אבטחת סייבר, אני מציע לך ללכת: https://www.first.org/tlp

---

DOUG.  ואתה יכול קרא עוד על כך באתר שלנו, nakedsecurity.sophos.com.

ואם אתם מחפשים קריאה קלה אחרת, תשכחו מהצפנה קוונטית... אנחנו ממשיכים קריפטוגרפיה שלאחר הקוונטים, פול!

---

ברווז.  כן, דיברנו על זה כמה פעמים בעבר בפודקאסט, לא?

הרעיון של מחשב קוונטי, בהנחה שאפשר לבנות מחשב קוונטי מספיק חזק ואמין, הוא שאפשר להאיץ סוגים מסוימים של אלגוריתמים על פני הטכנולוגיה של היום, בין אם לפי השורש הריבועי... או אפילו גרוע מכך, *לוגריתם* של קנה המידה של הבעיה כיום.

במילים אחרות, במקום לקחת 2²⁵⁶ מנסה למצוא קובץ עם hash מסוים, אולי תוכל לעשות את זה רק ("רק"!) 2¹²⁸ מנסה, שהוא השורש הריבועי.

ברור שהרבה יותר מהר.

אבל יש מחלקה שלמה של בעיות הקשורות לחלוקת תוצרים של מספרים ראשוניים לגורמים, שלפי התיאוריה ניתן לפצח ב*לוגריתם* הזמן שהם לוקחים היום, באופן רופף.

אז, במקום לקחת, נניח, 2¹²⁸ ימים להיסדק [הרבה יותר מהעידן הנוכחי של היקום], זה עלול לקחת רק 128 ימים להיסדק.

או שאתה יכול להחליף את "ימים" ב"דקות", או כל דבר אחר.

ולמרבה הצער, אותו אלגוריתם זמן לוגריתמי (נקרא אלגוריתם הפקטוריזציה הקוונטי של שור)... זה יכול להיות מיושם, בתיאוריה, על כמה מטכניקות ההצפנה של ימינו, בעיקר אלה המשמשות להצפנה עם מפתח ציבורי.

ובמקרה שמכשירי המחשוב הקוונטי יהפכו למעשיים בשנים הקרובות, אולי כדאי שנתחיל להתכונן עכשיו לאלגוריתמי הצפנה שאינם פגיעים לשני סוגים מסוימים של התקפה?

במיוחד הלוגריתם, מכיוון שהוא מזרז התקפות פוטנציאליות כל כך עד שמפתחות קריפטוגרפיים שאנו חושבים כרגע, "ובכן, אף אחד לעולם לא יבין את זה", עשויים להתגלות בשלב מאוחר יותר.

בכל מקרה, NIST, ה המכון הלאומי לתקנים וטכנולוגיה בארה"ב, כבר כמה שנים מנהלת תחרות כדי לנסות ולתקן כמה אלגוריתמים ציבוריים, ללא פטנט, שנבדקו היטב, שיהיו עמידים למחשבים הקוונטים הקסומים האלה, אם בכלל יופיעו.

ולאחרונה הם בחרו בארבעה אלגוריתמים שהם מוכנים לתקן כעת.

יש להם שמות מגניבים, דאג, אז אני חייב לקרוא אותם: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON, ו SPHINCS+. [צחוק]

אז יש להם שמות מגניבים, אם שום דבר אחר.

אבל, באותו זמן, NIST חשב, "ובכן, זה רק ארבעה אלגוריתמים. מה שנעשה זה שנבחר ארבעה נוספים כמועמדים משניים פוטנציאליים, ונראה אם ​​מישהו מהם צריך לעבור גם כן".

אז יש ארבעה אלגוריתמים סטנדרטיים כעת, וארבעה אלגוריתמים שעשויים להיות סטנדרטיים בעתיד.

או *היו* ארבעה ב-5 ביולי 2022, ואחד מהם היה SIKE, קיצור ל אנקפסולציה של מפתח איזוגני על יחיד.

(נזדקק למספר פודקאסטים כדי להסביר איזוגניות סופר-סינגולריות, אז לא נטרח. [צחוק])

אבל, למרבה הצער, זה, שהיה תלוי שם עם סיכוי לחימה להיות סטנדרטי, נראה כאילו הוא נשבר ללא תקנה, למרות שלפחות חמש שנים שכבר היה פתוח לביקורת ציבורית.

אז, למרבה המזל, רגע לפני שזה אכן זכה לסטנדרטיזציה, שני קריפטוגרפים בלגים הבינו, "אתה יודע מה? אנחנו חושבים שיש לנו דרך לעקוף את זה באמצעות חישובים שלוקחים כשעה, על מעבד ממוצע למדי, תוך שימוש בליבה אחת בלבד."

---

DOUG.  אני מניח שעדיף לגלות את זה עכשיו מאשר לאחר סטנדרטיזציה והוצאתו לטבע?

---

ברווז.  אכן!

אני מניח שאם זה היה אחד האלגוריתמים שכבר קיבלו סטנדרטיזציה, הם היו צריכים לבטל את התקן ולהמציא אחד חדש?

זה נראה מוזר שלא שמו לב לזה במשך חמש שנים.

אבל אני מניח שזה כל הרעיון של בדיקה ציבורית: אתה אף פעם לא יודע מתי מישהו עלול פשוט להכות בסדק הדרוש, או את הטריז הקטן שהוא יכול להשתמש בו כדי לפרוץ פנימה ולהוכיח שהאלגוריתם אינו חזק כפי שחשבו במקור.

תזכורת טובה שאם *אי פעם* חשבת לסרוג את ההצפנה שלך...

---

DOUG.  [צוחק] אני לא!

---

ברווז.  ..למרות שאמרנו לך בפודקאסט Naked Security N פעמים, "אל תעשה את זה!"

זו צריכה להיות התזכורת האולטימטיבית לכך שגם כאשר מומחים אמיתיים מוציאים אלגוריתם שנתון לביקורת ציבורית בתחרות עולמית במשך חמש שנים, זה עדיין לא בהכרח מספק מספיק זמן כדי לחשוף פגמים שמתגלים כגרועים למדי.

אז זה בהחלט לא נראה טוב בשביל זה SIKE אלגוריתם.

ומי יודע, אולי זה יבוטל?

---

DOUG.  אנחנו נשגיח על זה.

וכשהשמש שוקעת אט אט בתוכנית שלנו לשבוע זה, הגיע הזמן לשמוע מאחד הקוראים שלנו על הסיפור של GitHub שדיברנו עליו קודם לכן.

לשדוד כותב:

"יש קצת גיר וגבינה בתגובות, ואני שונא להגיד את זה, אבל אני באמת יכול לראות את שני הצדדים של הטיעון. האם זה מסוכן, מטריד, בזבוז זמן וצורך משאבים? כן, ברור שכן. האם זה מה שיעשו טיפוסים בעלי אופי פלילי? כן, כן, זה כן. האם זו תזכורת לכל מי שמשתמש ב-GitHub, או בכל מערכת מאגר קוד אחרת לצורך העניין, שנסיעה בטוחה באינטרנט דורשת מידה בריאה של ציניות ופרנויה? כן. כמנהל מערכת, חלק ממני רוצה לברך על חשיפת הסיכון שעל הפרק. כמנהל מערכת של חבורה של מפתחים, אני צריך עכשיו לוודא שכולם סרקו לאחרונה כל משיכה לערכים מפוקפקים."

---

ברווז.  כן, תודה לך, רובב, על ההערה הזו, כי אני מניח שחשוב לראות את שני הצדדים של הטיעון.

היו מגיבים שרק אמרו, "מה לעזאזל הבעיה עם זה? זה נהדר!"

אדם אחד אמר, "לא, למעשה, בדיקת העט הזו טובה ושימושית. תשמחו שהם נחשפים עכשיו במקום להרים את ראשם המכוער מתוקף ממשי".

והתגובה שלי לזה היא ש"ובכן, זו *זו* התקפה, למעשה."

רק שמישהו יצא עכשיו אחר כך ואמר "הו, לא, לא. לא נגרם נזק! בכנות, לא הייתי שובב."

אני לא חושב שאתה חייב לקנות את התירוץ הזה!

אבל בכל מקרה, זה לא בדיקת חדירה.

תגובתי הייתה לומר בפשטות רבה: "בודקי חדירה אחראיים פועלים רק [A] לאחר קבלת אישור מפורש, ו-[B] במגבלות התנהגות שהוסכם במפורש מראש."

אתה לא סתם ממציא חוקים משלך, ודיברנו על זה בעבר.

אז, כפי שאמר מגיב אחר, שהיא, לדעתי, התגובה האהובה עליי... אמר איקורב, "אני חושב שמישהו צריך ללכת מבית לבית ולנפץ חלונות כדי להראות עד כמה מנעולי דלת באמת לא יעילים. זה עבר את המועד. שמישהו יקפוץ על זה, בבקשה."

ואז, למקרה שלא הבנתם שזו סאטירה, אנשים, הוא אומר, "לֹא!"

---

ברווז.  אני מקבל את הרעיון שזו תזכורת טובה, ואני מקבל את הרעיון שאם אתה משתמש GitHub, גם כמפיק וגם כצרכן, יש דברים שאתה יכול לעשות.

אנו מפרטים אותם בהערות ובמאמר.

למשל, שימו חתימה דיגיטלית על כל המחויבויות שלכם, כך שברור שהשינויים הגיעו מכם, ויש איזושהי מעקב.

ואל תצרוך דברים בצורה עיוורת כי עשית חיפוש ו"נראה כאילו" זה יכול להיות הפרויקט הנכון.

כן, כולנו יכולים ללמוד מזה, אבל האם זה באמת נחשב ללמד אותנו, או שזה רק משהו שאנחנו צריכים ללמוד בכל מקרה?

אני חושב שזו *לא* הוראה.

זה פשוט *לא ברמה מספיק גבוהה* כדי להיחשב כמחקר.

---

DOUG.  דיון נהדר סביב המאמר הזה, ותודה ששלחת את זה, רוב.

אם יש לכם סיפור מעניין, תגובה או שאלה שתרצו לשלוח, נשמח לקרוא אותם בפודקאסט.

אתה יכול לשלוח דוא"ל tips@sophos.com; אתה יכול להגיב על כל אחד מהמאמרים שלנו; או שאתה יכול להתקשר אלינו בחברתית: @NakedSecurity.

זו ההופעה שלנו להיום - תודה רבה על ההקשבה.

עבור פול דאקלין, אני דאג אמות' שמזכיר לך, עד הפעם הבאה...

---

שניהם.  הישאר בטוח!

[מודם מוזיקלי]