קודם שיטת EAP: איזה hash סיסמה VPN יכולה להשתמש בו
VPN מאמת את הסוד, לא את ה-hash של האינטרנט. קראו את השיטה ואז בדקו מה המאגר מחזיק לפני שמבטיחים שאותן סיסמאות ימשיכו לעבוד.
להרבה צוותים יש התחברות אינטרנט שעובדת ו־VPN שמסרב לכל סיסמה מאותה טבלה. אפליקציית האינטרנט משווה hash שהיא חישבה בעצמה, בעוד המנהרה מבקשת מהלקוח להוכיח בעלות על סוד באופן שהשרת חייב להיות מסוגל לבדוק. אלה דרישות שונות מהחומר המאוחסן. בפער שביניהן נתקעים רוב הפרויקטים האלה.
קודם השיטה, אחר כך הסכימה
רשמו איזו הוכחה השיטה הנבחרת דורשת לפני שמסתכלים על סכימה כלשהי. שיטת אתגר־תגובה זקוקה לחומר שממנו השרת יכול לחשב את התגובה הצפויה, ובפועל משמעות הדבר היא הסיסמה או צורה נגזרת תואמת. שיטה שנושאת את הסיסמה בתוך מנהרה מוגנת זקוקה לסיסמה עצמה אצל המאמת. קראו את התיעוד של השיטה בגלל דרישת המאמת ולא בגלל תצורת הלקוח, כי דרישות הלקוח הן בדרך כלל החלק הקל.
hash עם מלח שמייצרת תשתית אינטרנט מודרנית לא נותן אף אחד מהשניים. הוא מאמת השוואה אחת מסוימת ואי אפשר להחזיר אותו לסוד שממנו נוצר.
אתגר־תגובה אינו יכול להשתמש ב-hash עם מלח
MSCHAPv2 הוא חילופי אתגר־תגובה, ולכן השרת לעולם אינו מקבל את הסיסמה ואינו יכול להשוות מחרוזת מאוחסנת. עליו לגזור את התגובה הצפויה מחומר שכבר ברשותו, ולכן הצורות המאוחסנות התואמות כל כך צרות. ערך bcrypt או Argon2 עם מלח לכל משתמש הוא חד־כיווני באופן ששולל את החילוף לחלוטין. הטבלה שלמטה מתחילה מצורת האחסון ולא משם השיטה, כי צורת האחסון היא שקובעת את התשובה.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
תיעוד תוסף ה-SQL עבור strongSwan מגדיר סכימה משלו לתצורה ולפרטי התחברות, והפרויקט עדיין מסמן את התוסף הזה כניסיוני. שום דבר בו אינו מסתגל לטבלת המשתמשים של אפליקציה או מנחש איזו סכמת hash יצרה ערך מאוחסן. האפשרויות הריאליות הן אפוא מעבר למאגר שהשער יכול להשתמש בו, או שירות אימות מול המאגר הקיים שיכול לבצע את החילוף. כל דבר אחר הוא מחבר עם הנחה נסתרת בתוכו.
RADIUS מעביר את העבודה, לא את הדרישה
האצלת EAP לשרת RADIUS משנה היכן האימות מתרחש ובדרך כלל משפרת את עקבות הביקורת. היא אינה משחזרת סיסמה מ-hash חד־כיווני, ולכן שירות האימות עדיין זקוק לחומר תואם לשיטה שהוא מסיים. צוותים מגלים זאת אחרי שהם בונים את מסלול RADIUS ונתקלים באותה חומה בצד השני.
היכן ששרת RADIUS יכול לקרוא ספרייה שמחזיקה פרטי התחברות תואמים, התכנון עובד והשער של VPN נשאר פשוט. היכן שלא, התשובה הכנה היא שינוי רישום ולא מחבר נוסף. הקצאה ושלילה שייכות למי שמחזיק בזהות, ולכן טבלה מועתקת בלי תהליך סנכרון נתמך היא מחזור חיים שני של פרטי התחברות ולא התחברות אחת. היא נסחפת בפעם הראשונה שמישהו מאפס סיסמה במקום אחד בלבד, והסחיפה שקטה עד שחשבון שקיים בשתי המערכות מתנהג אחרת בכל אחת.
הגבילו את החשבון שקורא את הספרייה לקריאה הזו בלבד, והחזיקו אותו בנפרד מהחשבון שהשער משתמש בו לתצורה שלו. חשבון ניהולי משותף הופך תכנון לקריאה בלבד לרדיוס פגיעה רחב בהרבה.
היכן החשבון צריך לחיות
לאחר שנפתרה שאלת החומר, נשארות שתי ארכיטקטורות. השער יכול להחזיק מאגר קטן של פרטי התחברות שרק הוא קורא, או להאציל לשירות אימות שעומד מול ספריית הארגון.
הראשונה קלה יותר לחשיבה ורעה יותר למשתמש, שנשאר עם סיסמה שנייה לתחזק. השנייה שומרת על זהות אחת ומוסיפה תלות בשירות שעכשיו חייב להיות פעיל לפני שמישהו יכול להתחבר. אף אחת מהן אינה שגויה, אבל הבחירה צריכה להירשם לצד תצורת השער, אחרת המהנדס הבא יניח שנבחרה האחרת. מה שתבחרו, שתי הפקודות שלמטה הן אלה שמראות את המצב הנוכחי לפני שתשנו אותו.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsאימות חשבון גם אינו פותר הרשאה. חברות בקבוצה, מצב ההתקן והרשאת הרשת עדיין דורשים מיפוי מפורש אחרי שהמשתמש הוכיח את הזהות הנדרשת. חיבור שמאמת באופן מושלם ולא מעניק הרשאה לדבר הוא תוצאה של מדיניות, לא תקלה בשיטה.