בדקו בנפרד כניסה לחשבון, הרשאת גישה לנתונים ושחזור מפתחות צ׳אט; כפתור כניסה אחד אינו תשובה לשלושתם.
״כניסה עם Google״ אינה אומרת אוטומטית של־Google יש גישה לטקסט הצ׳אט, וגם אינה אפשרות שאין לה מחיר במונחי אמון. השיטה מכניסה ספק זהות לתהליך הכניסה; יש לבדוק את המידע המועבר ואת תלות החשבון על סמך ההרשאות והתכנון בפועל של השירות.
כדי להחליט, הפרידו בין כניסה לחשבון, הרשאת גישה לנתוני Google ומפתחות הצפנת השיחות. כפתור כניסה אחד אינו תשובה לכל שלוש השאלות.
מה ההבדל בין OAuth ל־OpenID Connect?
OAuth הוא מסגרת למתן גישה למשאבים. OpenID Connect מספק מעליה שכבת אימות זהות. תיעוד הכניסה של Google מסביר את התהליך המבוסס על OpenID Connect לזיהוי המשתמש.
לכן האמירה ״OAuth מוסר את סיסמת Google למסנג׳ר״ אינה נכונה. השירות חייב לאמת כראוי את האסימון הרלוונטי ולאבטח את ההפעלה שלו. הרשאה ל־Gmail, ל־Drive או לנתונים אחרים היא גם עניין נפרד מעצם הכניסה. הסבר על הרשאות ותחומי גישה.
איזה מידע עשוי לעבור?
תהליך הכניסה מעביר לשירות בדרך כלל מזהה, ובהתאם להרשאות גם מידע כגון כתובת דוא״ל או פרטי פרופיל. ספק הזהות משתתף גם בבקשות הקשורות לאימות. אבל משם שיטת הכניסה אי אפשר להסיק שכל פתיחה של האפליקציה, כל הודעה או כל היסטוריית השימוש נשלחות לספק הזהות.
| שאלה | מה צריך לבדוק |
|---|---|
| אילו פרטי חשבון מקבל המסנג׳ר? | מסך ההסכמה, תחומי הגישה ומדיניות הפרטיות |
| האם התבקשה הרשאה לנתונים נוספים? | ההבדל בין כניסה לבין גישה לדוא״ל, לקבצים או לאנשי קשר |
| מתי ספק הזהות מעורב שוב? | מדיניות ההפעלות ורענון האסימונים במימוש |
| האם מפתחות הצ׳אט תלויים בכניסה הזו? | תיעוד אחסון ושחזור המפתחות, ולא רק כפתור הכניסה |
הימנעו ממתן הרשאה שאי אפשר להצדיק ביחס לצורך שלכם. לצד זאת, אל תפרשו בקשת הרשאה מסוימת כ״קריאת כל ההודעות״ בלי לבדוק.
מה הסיכון בתלות בחשבון מרכזי?
אם הדרך היחידה שלכם להיכנס למסנג׳ר היא חשבון שהופך לבלתי נגיש, כניסה חדשה עלולה להיפגע. ההשפעה על הפעלות קיימות, נתונים מקומיים ושחזור תלויה בתכנון השירות. לכן ״חסימה של Google בהכרח משמידה את כל הצ׳אטים״ אינה מסקנה נכונה.
לפני מצב חירום, בדקו אם השירות מציע שיטת כניסה חלופית או תהליך שחזור, וכיצד הוספתם משפיעה על אבטחת החשבון. הדרך החלופית אינה צריכה להפוך לדרך קלה יותר לתוקף. אל תשנו או תסירו את קישור החשבון בלי לוודא שתוכלו להיכנס לאחר מכן.
האם כניסה ישירה באמצעות SRP מבטלת את כל הסיכונים האלה?
כניסה ישירה יכולה להפחית תלות בספק זהות חיצוני. גם SRP, במימוש נכון, מוכיח ידיעת סיסמה בלי לשלוח את הסיסמה עצמה בהודעות הפרוטוקול. אבל שירות המסרים עדיין מעבד את שם החשבון, את אירוע הכניסה ומידע תפעולי קשור; ״בלי טביעת רגל דיגיטלית״ אינו תיאור מדויק.
בנוסף, יש להגן על ערך האימות השמור של SRP. RFC 5054 מתאר את הסיכון לניחוש הסיסמה לאחר חשיפת ה־verifier. אבטחת דף הכניסה, ההפעלה, השחזור והמכשיר עדיין חיונית.
אין עיקרון טכני שקובע ש־SRP הוא דרך הכניסה הפרטית היחידה או שכל כניסה מאוחדת אינה בטוחה מטבעה. איכות המימוש ומודל האיומים צריכים להכריע.
גבולות הטענות של Livara
דף האבטחה של Livara מתאר SRP לאימות זהות וגם מציין במפורש שמירת נתונים תפעוליים מסוימים. אין פירוש הדבר שזהות החשבון מוסתרת מהשירות עצמו. אותו דף מבחין בין שחזור הזהות הקריפטוגרפית לבין היסטוריית הצ׳אט.
לצורך השוואה מעשית, בקשו מכל שירות תשובות לאותן שאלות: איזה מידע הוא מקבל, איזה צד שלישי מעורב, כיצד הוא מסיים הפעלה וכיצד משוחזרים מפתחות הצ׳אט? תשובה מתועדת מועילה יותר מהסיסמה ״אפס ידע״.
לפני שבוחרים שיטת כניסה
אבטחו את החשבון הראשי ואת דרכי השחזור, קראו את ההרשאות המבוקשות, סקרו את המכשירים המקושרים והכירו את התוכנית למקרה של אובדן גישה לחשבון. לאחר מכן בחרו שיטת כניסה המתאימה לצרכים שלכם וליכולת הניהול שלכם; לנוחות ולעצמאות יש ערך, אך אף אחת מהן אינה מבטיחה אבטחה בפני עצמה.
