מחשבות, מחשבים, ושאר דברי בלע

יש שתי בעיות עם טביעות אצבעות, false negative וfalse positive.

• false negative (שלילי שגוי) : כאשר בהנתן דוגמא של טביעת אצבע, אנחנו לא מוצאים התאמה במאגר למרות שהמאגר מכיל התאמה.
• false positive (חיובי שגוי) : כאשר בהינתן דוגמא של טביעת אצבע, אנחנו מתאימים אותה לטביעת אצבע לא מתאימה במאגר.

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

מכיוון שלא כל הממצאים יופיעו בכל טביעה (טביעה חלקית, זווית לחיצה וכו’) וגם אם יופיעו כולם, הם לא יהיו במרחקים שווים אחד מהשני, משתמשים בהתאמה מקורבת, בגבולות threshold מסויים.
התאוריה הרווחת היא שאין שני אנשים עם טביעות אצבע זהות (למרות שאף אחד לא באמת בדק את כל אוכלוסית העולם). גם אם אנחנו מקבלים את התאוריה, היא עדיין לא אומרת שאלגוריתם הבדיקה לא יכריז על שתי טביעות ממקורות שונים כזהות כי הן דומות מספיק.|
יש תיעוד של כמה מקרים של זיהוי חיובי שגוי, שהצליחו לקלקל לכמה אזרחים תמימים את הבוקר, או את השבוע, או את העשור. (וניתן להניח שיש גם כמה טעויות שלא התגלו ודפקו לאנשים את החיים).
אז שגיאות קורות, אבל אולי הן נדירות מאוד?
נניח לשם השעשוע שבהינתן שתי טביעת אצבע מאנשים שונים, הסבירות ששתיהן יזוהו כשיכות לאותו אדם היא אחד למליון, נשמע טוב?
עכשיו, נניח שבונים מאגר ביומטרי של כל אזרחי המדינה (קצת יותר משבע מליון איש נכון לסוף 2008):
עם סבירות של אחד למליון, בהינתן טביעת אצבע, יהיו לה בממוצע שבע התאמות חיוביות שגויות במאגר.

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

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

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

מומלץ לקרוא את כל הכתבה בYNET.

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

איך נמנע זיוף זהות?

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

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

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

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

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

ועל זה נאמר:
זאב! זאב!

אז, לא – לדעתי זה לא מספיק.

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

לא כיף לקום בבוקר ולראות בתיבת האימייל שלכם הודעה על כך שיצאה התקפת SSH מהשרת שלכם ושהוא כנראה נפרץ.
ככה בדיוק התחיל היום שלי אתמול.

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

שיניתי את הסיסמא של המשתמש, והרגתי את כל התהליכים שרצו תחת שם המשתמש שלו (מה שכמובן ניתק את המשתמש)

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

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

מה שהפורץ עשה אחרי שהוא ניחש את הסיסמא זה להפעיל סורק SSH שהתחבר לכתובות IP באופן שיטתי (אפשר לראות שהוא ניסה תחומי כתובות שלמים) ופשוט ניחש סיסמאות לפי קובץ סיסמאות מוכן.
מספיק שהוא יצליח להיכנס בשבריר אחוז מהנסיונות כדי להרחיב את רשימת השרתים שיש לו אליהם גישה.
בטח על חלק מהשרתים הוא גם מצליח להשיג גישת ROOT באותה שיטה.

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

אז בתור התחלה, אפשר להשתמש בgpw כדי לבחור סיסמאות למשתמשים חדשים.

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

ואז עריכת הקובץ /etc/pam.d/common-password והוספת הערה לפני השורה הראשונה, והסרת ההערות מהשתיים האחרות:

אפשר גם לדרוש החלפה של הסיסמא לכל היותר תוך מספר ימים מסויים על ידי עריכה של /etc/login.defs ושינוי הערך של PASS_MAX_DAYS

בדיקה נוספת שאפשר לבצע היא בדיקה שיטתית של הסיסמאות במערכת שלכם הן חזקות או לא על ידי הפעלת תוכנה שמנסה לפרוץ אותן באופן קבוע.
תוכנה כזו היא john המרטש שמנסה לפרוץ את הסיסמאות המקומיות ממש כאילו היא האקר עויין, רק שאם היא מצליחה היא תדווח לכם ואם תרצו גם למשתמש הספציפי שהסיסמא שלו חלשה.
מכיוון שהוא רצה כROOT היא יכולה לבצע את נסיון הפריצה ישירות על הקובץ, מה שיהיה יעיל יותר מאשר לנסות להיכנס דרך SSH.
בהתקנת ברירת המחדל בדביאן ג’והן המרטש מתקין ג’וב קרון שרץ בלילה בין 1 בלילה ל7 בבוקר (זמן שרת), אבל צריך לאפשר אותו על ידי הסרה של ההערות מהשורות הבאות בקובץ /etc/cron.d/john (פשוט מחיקת ה# המקדימים)

כלי נוסף שאפשר להתקין הוא tripwire שעוקב אחרי שינויים בלתי קרואים לקבצי מערכת.
הזמן הנכון להתקין את tripwire הוא לפני שהמערכת שלכם נפרצה (ואני מדבר על פורץ שהשיג גישת ROOT).
אחרי ההתקנה עם apt-get עקבו אחרי ההוראות הפשוטות פה כדי ליצור את בסיס הנתונים שמולו tripwire יזהה שינויים בעתיד.
מומלץ מאוד לאכסן את בסיס הנתונים של tripwire במקום ללא גישת כתיבה כדי למנוע מתוקף עם גישת ROOT לשנות את בסיס הנתונים ובכך להסתיר את השינויים שהוא עשה.

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

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

שאלתי כבר, האם מייקרוסופט משתנה?

——————–

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

עוד על זה כאן.

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

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

החלטתי לצ’פר משתמשי פיירסטטס שתורמים ולתת כמה פיצ’רים למי שתורם בלבד.
מכיוון שאני מקבל את התרומות דרך Paypal חשבתי שזה יהיה נחמד לדאוג לאיזה תהליך אוטומטי שישלח לתורמים אימייל עם לינק להורדה של הפיצ’רים הנוספים.
פניתי לאתר של Paypal, שתומך במשהו שנקרא IPN : Instant payment notification.
בקצרה, האתר של Paypal קורא לURL שאתם מספקים לו ומעביר לו פרטים על הטרנזקציה (מי זה, כמה הוא נתן, וכו’).
האתר שלכם מאמת את הפרטים מול Paypal, ומכניס אותם לבסיס הנתונים ועושה מה שאתם רוצים.

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

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

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

מה שזה אומר זה שכל מי שהשתמש בקוד לדוגמא שלהם בלי לשים לב לבעיה (אני מניח ש99% מהמשתמשים) יצר לעצמו בעיית אבטחה בשרת, בדיוק בנקודה הקריטית שנוגעת לכסף.

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