OpenVPN מפיל סשן OTP מאוחר יותר: מה נדרש לאימות מחדש
סשן שמת לאחר שעה הוא בדרך כלל חידוש מפתח שמבקש קוד שכבר נוצל. בחרו בין טוקן שהשרת מנפיק לבין אתגר אינטראקטיבי חדש.
מנקודת המבט של הלקוח זה נראה כמו ניתוק אקראי שעה אחרי תחילתו של סשן עובד. סמל המגש נעלם, המנהרה נבנית מחדש, והיומן מציג כשל אימות ולא שגיאת רשת. מה שקרה בפועל הוא שהסשן ניהל משא ומתן מחדש ולחיצת היד השנייה נזקקה לאישורים שלקוח כבר לא החזיק בהם עותק תקף. קוד חד-פעמי שעבד בכניסה לא יכול לעבוד שוב, ולכן חידוש המפתח נכשל בדיוק כמתוכנן.
התיקון הוא החלטה מה על לחיצת היד השנייה להציג, ולא טיימר ניסיון חוזר ארוך יותר.
עקבו אחרי ההחלפה מנקודת המבט של הלקוח
בכניסה הלקוח שולח את שם המשתמש, הסיסמה וקוד מהתקן הטוקן, והשרת מקבל את הצירוף. לאחר מכן הסשן פועל עד שמופעל גורם ניהול משא ומתן מחדש, שפותח לחיצת יד TLS חדשה בתוך המנהרה הקיימת. לחיצת היד הזו מבקשת אימות שוב. אם נתיב האימות של השרת מצפה לסיסמה ועוד קוד חד-פעמי עדכני, ללקוח אין קוד חדש להציע אלא אם המשתמש נוכח כדי להקליד אחד.
רוב הלקוחות לא פותחים בקשה באמצע הסשן, ולכן לחיצת היד פגה והמנהרה נופלת. המשתמש רואה התחברות מחדש, לא בקשת אימות, ולכן הדיווח הראשון מאשים בדרך כלל את הרשת.
auth-gen-token משנה מי עונה על השאלה השנייה
auth-gen-token היא האפשרות שמאפשרת לשרת להנפיק טוקן לאחר כניסה מוצלחת, וניהולי משא ומתן מחדש מאוחרים מציגים את הטוקן הזה במקום לחזור על הסיסמה והקוד. המדריך מתעד את חייו והתנהגות החידוש שלו, ויש להתייחס לטוקן כאישור עם תפוגה משלו. בנתיב ברירת המחדל השרת מאמת את הטוקן בעצמו במקום לקרוא שוב למאמת הסיסמה החיצוני.
עם שילוב אימות חיצוני, החלוקה הזו משתנה. התוסף צריך להבין את מצב הטוקן ולהחיל בדיקות משלו, כי השרת כבר אינו הרכיב היחיד שמחליט אם הסשן נמשך. התייחסות לטוקן כעוד קוד ספרתי חד-פעמי אינה מימוש של התכונה.
החליטו מה קורה למצב החשבון
טוקן ששורד את הגישה של חשבון הוא חור במדיניות. החליטו כיצד חשבון מושבת, חברות בקבוצה שהוסרה או התקן שנשלל נכנסים לתוקף בזמן שהטוקן עוד תקף. חיי טוקן קצרים מקטינים את החלון; נתיב שלילה מפורש הופך אותו מכוון. כתבו את התשובה לפני הפעלת האפשרות, כי נתיב ברירת המחדל אינו מתייעץ עם המאמת החיצוני בכל ניהול משא ומתן מחדש.
בפריסה רבת שרתים, סוד החתימה של הטוקנים חייב להיות משותף, אחרת הלקוח עלול להישלח לצומת שאינו יכול לאמת את הטוקן שלו.
בדקו תפוגה והתחברות מחדש, לא רק כניסה
הקטינו את מרווח ניהול המשא ומתן מחדש בפרופיל בדיקה כדי שלחיצת היד השנייה תקרה בזמן שאתם צופים, ואז עקבו אחרי שני היומנים. ודאו שהטוקן מונפק בכניסה, מוצג בחידוש המפתח, ומתרענן או מונפק מחדש לפי משך החיים שהוגדר. לאחר מכן כפו תפוגת טוקן והתחברות מחדש מלאה, כי לקוח שמתחבר מחדש בצורה נקייה עדיין עלול להיכשל בנתיב חידוש המפתח.
בדקו הסרת חשבון אחרונה. המקרה הזה אומר לכם אם המדיניות שכתבתם נאכפת או רק מתועדת.
אל תתקנו את זה על ידי השבתת החידוש
קביעת מרווח ניהול המשא ומתן מחדש לאפס בשני הצדדים מסירה את התסמין ואת סבב המפתחות יחד איתו. זה מסתיר בעיית שימוש חוזר באישורים מאחורי שינוי מדיניות שאיש לא סקר. שמרו על החידוש, ובחרו בין טוקן שהשרת מנפיק לבין אתגר אינטראקטיבי חדש לפי אם משתמש נוכח.
טיימר ניסיון חוזר ארוך יותר לא הופך קוד שנוצל לתקף שוב. הוא רק דוחה את הניתוק והופך את היומן לקשה יותר לקריאה.