שתי בקשות סיסמה אינן MFA: מה כניסה ל-VPN מאמתת
שדה סיסמה שני, הצפנה חזקה ותעודת מכשיר כל אחד מוכיח משהו. רק גורמים נפרדים הקשורים לחשבון אחד נחשבים לרב-גורמיים.
עמוד הכניסה מבקש סיסמה, ואחר כך סוד שני, והפריסה מתוארת מיד כרב-גורמית. לפעמים זה נכון. לעתים קרובות זה גורם אחד שנאסף פעמיים, מפני ששני הערכים הם ידע שאותו אדם הקליד מאותו זיכרון או מאותה הערה. הצפנת מנהרה חזקה לא משנה זאת, וגם לא המילה „מאובטח” בשם המוצר.
הפרדת הטענה מהמנגנון דורשת שאלה אחת: מה כל שלב מוכיח, ולמי?
גורם הוא הוכחה, לא שדה
אימות רב-גורמי משמעו שמאומת יותר מסוג אחד נפרד של הוכחה עבור אותו חשבון: משהו שהמשתמש יודע, משהו שהוא מחזיק, משהו שהוא. שני שדות ששניהם אוספים מחרוזת זכורה הם סוג הוכחה אחד שנדרש פעמיים. זה יכול להיות בקרה שימושית, מפני ששני סודות בלתי תלויים קשים יותר לניחוש מאחד, אבל זה אינו מה שהמונח מתאר ואסור לספור אותו כך בהערכת סיכונים.
צד האימות חשוב לא פחות מצד האיסוף. קוד שנוצר במכשיר מוכיח שליטה באותו מכשיר רק אם השרת בודק אותו מול סוד הקשור לחשבון הזה ודוחה חזרות. קוד משותף שעובד לכולם, קוד ללא הגבלה, או בקשה שמאושרת במכשיר שלעולם אינו מציג מה מאושר, כולם חלשים מכפי שהתווית מרמזת.
לכן כשמישהו שואל אם ל-VPN יש MFA, שאלו מה השלב השני מוכיח ואיך השרת קושר אותו. אם התשובה היא „סיסמה שנייה מאותו ספרייה”, יש לכם גורם אחד ושיחה על מדיניות, לא גורם שני.
מקרה התעודה צריך לקרוא, לא להניח
תעודת לקוח יחד עם סיסמה נראית כמו שני גורמים, וזה יכול להיות כך: התעודה נשמרת במאגר או על אסימון, והסיסמה נזכרת. זה יכול להיות גם גורם אחד, אם קובץ התעודה נמצא ללא הגנה באותה תיקיית פרופיל כמו הסיסמה השמורה, או אם התעודה הונפקה למכשיר שמספר אנשים חולקים בלי אחריות אישית.
השאלה שיש להכריע בה היא את מי או מה התעודה מזהה. תעודת מכשיר מוכיחה שמכונה מנוהלת נוכחת. תעודת משתמש מוכיחה זהות. אם הפריסה מנפיקה תעודה אחת לכל מחשב נייד ואז מתייחסת לנוכחותה כהוכחה לאדם, הגורם השני הפך בשקט לתכונה של חומרה שכל מי שמחזיק במחשב הנייד יורש.
שום דבר מזה לא הופך תעודות לרעיון רע. זה הופך את ההבחנה בין הבטחת מכשיר להבטחת משתמש לראויה לרישום, מפני ששתיהן עונות על שאלות שונות, וגיליון ציות שסופר אותן כאחת יגזים במה שמוגן.
אמון בשער ואמון במשתמש הם בעיות נפרדות
גורם שני לא הופך את ההקלדה של פרטי התחברות לנקודת קצה שלא אימתתם לבטוחה. הלקוח חייב לזהות את השער המיועד, ולשם כך קיימים תעודת השרת ותצורת האמון של הלקוח. פישינג פועל בהעברת הכניסה לשרת שהתוקף שולט בו, וקוד חד-פעמי נכון שהוקלד שם פשוט מועבר לשירות האמיתי בזמן אמת.
לכן בחירת השיטה משנה את התוצאה יותר מניסוח הבקשה. קודים שאדם מקליד יכולים להיות מועברים על ידי כל מי שיכול להציג עמוד משכנע, בעוד ששיטות קריפטוגרפיות שקושרות את האימות למקור ולסשן המסוימים מתנגדות להעברה הזו מלכתחילה. איזו מהן יש לכם היא תכונה של השיטה, לא של מספר השלבים בתיבה.
עקבו אחרי תהליך הרישום וזרימת הלקוח הנתמכים על ידי הספק במקום להבריג בקשה נוספת לשדה סיסמה. שלב שני תוצרת בית נוחת בדרך כלל אי שם בין השניים, ומוסיף חיכוך בלי הקישור שהופך את הגורם למשמעותי.
שחזור הוא הדלת הקדמית השנייה
לכל כניסה חזקה יש דרך חזרה כשהמאמת אבד, ובדיוק הדרך הזו היא לרוב הנקודה החלשה ביותר בתכנון. אם סוכן תמיכה יכול לאפס את הגורם השני אחרי שיחה למספר הרשום, המסלול הזול ביותר לתוקף הוא שולחן העזרה, לא עמוד הכניסה.
שאלו איך עובד ההחלפה, מי מאשר אותה ואילו ראיות נדרשות. אחר כך בדקו שחומר השחזור, כמו קודי גיבוי, נשמר בנפרד מהרשאה הראשית, כדי שפגיעה אחת לא תמסור את שניהם. הנחיות NIST לזהות דיגיטלית מתייחסות לקישור המאמת ולמחזור החיים של המאמת כחלק מהדרישה, ולא כהרהור תפעולי שלאחר מעשה.
מה לכתוב בהערכה
תארו את הגורמים לפי סוג, ציינו מה כל אחד מוכיח ופרטו כיצד הוא קשור לחשבון. ציינו אם השיטה מתנגדת להעברה, ותארו את מסלול השחזור באותה זהירות כמו את הכניסה.
אחר כך אמרו בבירור אם הפריסה רב-גורמית לפי אותה הגדרה. „שתי סיסמאות ותעודת מכונה” היא משפט כן, והוא מספר לקורא הרבה יותר מתיבת סימון שאומרת כן.