כל מה שרצית לדעת על איפוס סיסמה מאובטחת. חלק 2

אימות דו-גורמי

כל מה שאתה קורא בו החלק הראשון זיהוי מודאג על בסיס זה המבקש יודע. הוא יודע את כתובת האימייל שלו, הוא יודע איך לגשת אליה (כלומר הוא יודע את סיסמת המייל שלו), והוא יודע את התשובות לשאלות האבטחה שלו.

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

ברוב המקרים, ביצוע זיהוי ביולוגי אינו אפשרי, במיוחד כאשר אנו מדברים על אבטחת יישומי אינטרנט, כך שאימות דו-גורמי (2FA) משתמש בדרך כלל בתכונה השנייה - "מה שיש לך". וריאציה פופולרית אחת של גורם שני זה היא אסימון פיזי, למשל. מזהה מאובטח של RSA:

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

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

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

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

כעת עלינו לבחור להתחיל בתהליך האיפוס:

פעולה זו גורמת למייל להישלח לכתובת הרשומה:

האימייל הזה מכיל את כתובת האתר לאיפוס:

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

זה ה-SMS:

לאחר הזנתו לדפדפן, חזרנו לטריטוריית איפוס הסיסמה הקלאסית:

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

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

עם זאת, מכשיר זה יכול לקבל SMS и קבל אימיילים לאיפוס סיסמה:

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

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

איפוס לפי שם משתמש לעומת איפוס לפי כתובת אימייל

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

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

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

אימות זהות ודיוק כתובת הדוא"ל

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

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

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

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

זיהוי מי יזם את תהליך האיפוס

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

הנה דוגמה מפונקציית האיפוס שאני בונה כעת לתוך ASafaWeb:

הקישור "למידע נוסף" מעביר את המשתמש לאתר ip-address.com, דיווח על מידע כגון המיקום והארגון של מבקש האיפוס:

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

הודעה על שינויים במייל

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

יכולות להיות שתי סיבות לשינוי הסיסמה:

1. שינוי סיסמה לאחר הכניסה כי המשתמש רוצה סיסמה חדשה
2. איפוס סיסמה ללא כניסה מכיוון שהמשתמש שכח אותה

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

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

אה, ולמקרה שזה לא היה ברור כבר - אין לשלוח סיסמה חדשה בדואר! זה עשוי להצחיק חלק מהאנשים, אבל דבר כזה קורה:

יומנים, יומנים, יומנים ועוד כמה יומנים

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

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

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

האצלת אחריות למבצעים אחרים

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

כיום, ישנם ספקי צד שלישי רבים ששמחים לקחת על עצמם את כל הכאב ולהתפשט הכל לשירות מנוהל אחד. שירותים כאלה כוללים OpenID, OAuth ואפילו Facebook. אנשים מסויימים יש אמונה בלתי מוגבלת במודל הזה (OpenID אכן הצליח מאוד ב-Stack Overflow), אבל אחרים הם ממש רואים בה סיוט.

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

איפוס זדוני

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

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

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

החוליה החלשה ביותר

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

ASafaWeb מתארח בשירות מדהים שמסופק על ידי AppHarbor. תהליך איפוס חשבון אירוח הולך כך:

שלב 1:

שלב 2:

שלב 3:

שלב 4:

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

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

מחברים את הכל ביחד

הפוסט הזה מכיל מידע רב, אז אני רוצה לתמצת אותו למתווה ויזואלי פשוט:

זכור לרשום מפורט ככל האפשר עבור כל אחד מהפריטים הללו. זהו, זה פשוט!

תוצאות של

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

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

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

על זכויות הפרסום

VDSina מציע לא יקר שרתים להשכרה בתשלום יומי, כל שרת מחובר לערוץ אינטרנט של 500 מגה-ביט ומוגן מפני התקפות DDoS בחינם!

מקור: www.habr.com