לאן הולך קוד האתגר הסטטי בהתחברות OpenVPN

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

התחילו מההנחיה שהלקוח שלכם באמת מציג

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

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

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

מה שהשרת כבר חייב לתמוך בו

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

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

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

השדה המקודד שממשק הניהול שולח

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

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

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

סטטי מול דינמי: תזמון שונה

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

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

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

בדקו גם הצלחה וגם כישלון, לא רק את תיבת הדו-שיח

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

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