התייחסו למספר חשבון סודי כאל אישור גישה: בצעו עליו ביקורת

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

מפו מה החזקה מעניקה בפועל

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

את המודל הכללי קל לנסח: אישור bearer הוא כזה שהמחזיק יכול להשתמש בו בלי להוכיח החזקה במפתח קריפטוגרפי נפרד, וזהו ההבדל ש RFC 6750 משרטט לאסימונים. זו השוואה, לא טענה ששירות מבוסס מספר מיישם OAuth. אם המחזיק אינו זקוק לדבר אחר, התייחסו למספר כאל סוד bearer וסווגו את שאר התכנון בהתאם.

הגנו עליו כסוד, לא כהפניה

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

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

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

בדקו יחד את עמידות הניחוש ואת הגבלת הקצב

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

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

# one attempt, then read the response and any counter or delay
# do not script repeated guesses against a live account
curl -i -X POST https://portal.example.invalid/login -d "account=000000000000"

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

תכננו סבב וביטול לפני שתצטרכו אותם

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

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

תעדו את ההחלטה ובדקו אותה שוב מאוחר יותר

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

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

לפני שתשמרו אותו:

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