הפעלה או השבתה של הגנה מפני ספירת כתובות אימייל

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

חשוב: מומלץ להפעיל הגנה מפני ספירת כתובות אימייל בכל הפרויקטים.

סקירה כללית

ספירת אימיילים היא סוג של מתקפת כוח ברוטלית שבה גורם זדוני מנסה לנחש או לאשר משתמשים במערכת על ידי העברת כתובת אימייל ל-API ובדיקת התגובה.

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

• נעשה ניסיון להיכנס באמצעות כתובת אימייל שלא קיימת במערכת. פלטפורמת Identity Platform מחזירה שגיאת EMAIL_NOT_FOUND.

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

אתם יכולים להשתמש בתכונה להגנה מפני ספירת כתובות אימייל ב-Identity Platform כדי להגן על חשבונות משתמשים באפליקציה שלכם מפני התקפות כאלה.

כשמופעלת הגנה מפני ספירת כתובות אימייל, הפרויקט מתנהג כך:

• ממשק ה-API ‏fetchSignInForEmail ייכשל. קישור משתמשים אנונימיים מאומתים לכתובת אימייל לא יפעל גם לפני גרסה 22.3.0 של SDK ל-Android, גרסה 10.18.0 של SDK ל-iOS וגרסה 10.6.0 של SDK לאינטרנט.

• כשמבצעים קריאה ל-API בארכיטקטורת REST‏ createAuthUri או ל-method‏ fetchSignInMethodsForEmail של client SDK בכל הפלטפורמות, לא מוחזרת יותר רשימה של שיטות כניסה לכתובת אימייל ספציפית.

• המשתמשים לא יכולים לשנות את כתובת האימייל שלהם בלי לאמת קודם את הכתובת החדשה. לדוגמה, אי אפשר יותר לשנות את כתובת האימייל של משתמש באמצעות update API בארכיטקטורת REST,‏ setAccountInfo API בארכיטקטורת REST או שיטת updateEmail client SDK בכל הפלטפורמות.

  אפשר להשתמש ב-verifyBeforeUpdateEmail לאינטרנט ול-Android או ב-sendEmailVerification(beforeUpdatingEmail:) ל-iOS במקום זאת.

• אי אפשר יותר להשתמש ב-setAccountInfo REST API כדי לקשר ספק של כתובת אימייל או סיסמה לחשבון משתמש קיים. אי אפשר יותר להשתמש בשיטת הלקוח SDK‏ linkWithCredential עם EmailAuthCredential בכל פלטפורמה. במקום זאת, משתמשים ב-API בארכיטקטורת REST signUp, מעבירים את אסימון המזהה של המשתמש בשדה idToken ואת השדות email ו-password לקישור.

• הוסרה תגובת השגיאה לתהליכי אימות אימייל, כולל תהליכים שהופעלו על ידי קריאה ל-API בארכיטקטורת REST‏ sendOobCode עם סוגי הבקשות VERIFY_AND_CHANGE_EMAIL או PASSWORD_RESET, ועל ידי קריאה ל-verifyBeforeUpdateEmail לאינטרנט ול-Android, ל-sendEmailVerification(beforeUpdatingEmail:) ל-iOS או ל-sendPasswordResetEmail בכל הפלטפורמות.

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

  מומלץ לא לאפשר למשתמשים להירשם בלי תהליך אימות של כתובת האימייל.

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

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

המלצות בנושא אבטחה

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

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

• אם יצרתם את הפרויקט לפני 15 בספטמבר 2023, ההגנה מפני ספירת כתובות אימייל לא מופעלת אוטומטית.

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

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

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

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

הפעלה של הגנה מפני ספירת כתובות אימייל

כדי להפעיל את ההגנה מפני ספירת כתובות אימייל, פועלים לפי השלבים הבאים:

מסוף Firebase

1. במסוף Firebase, עוברים לדף הגדרות אימות.

   מעבר אל Authentication Settings

   1. בחלונית ניהול חשבונות משתמשים, בוחרים באפשרות פעולות משתמש.

   2. בוחרים באפשרות הגנה מפני ספירת כתובות אימייל (מומלץ).

2. לוחצים על Save.

REST

1. במסוף Google Cloud , מריצים את הפקודה gcloud auth print-access-token כדי להדפיס אסימון גישה למזהה הפרויקט:

   gcloud auth print-access-token --project=PROJECT_ID
   

2. מפעילים הגנה על ספירת כתובות אימייל עבור מזהה הפרויקט שלכם באמצעות Identity Toolkit API:

   curl -X PATCH -d "{'emailPrivacyConfig':{'enableImprovedEmailPrivacy':true}}" \
       -H 'Authorization: Bearer ACCESS_TOKEN' \
       -H 'Content-Type: application/json' -H 'X-Goog-User-Project: PROJECT_ID' \
       "https://identitytoolkit.googleapis.com/admin/v2/projects/PROJECT_ID/config?updateMask=emailPrivacyConfig"
   

מחליפים את מה שכתוב בשדות הבאים:

• ‫ACCESS_TOKEN: אסימון הגישה שיצרתם קודם
• ‫PROJECT_ID: מזהה הפרויקט

השבתת ההגנה מפני ספירת כתובות אימייל

כדי להשבית את ההגנה מפני ספירת כתובות אימייל, פועלים לפי השלבים הבאים:

מסוף Firebase

1. במסוף Firebase, עוברים לדף הגדרות אימות.

   מעבר אל Authentication Settings

   1. בחלונית ניהול חשבונות משתמשים, בוחרים באפשרות פעולות משתמש.

   2. מבטלים את הסימון של הגנה מפני ספירת כתובות אימייל (מומלץ).

2. לוחצים על Save.

REST

1. במסוף Google Cloud , מריצים את הפקודה gcloud auth print-access-token כדי להדפיס אסימון גישה למזהה הפרויקט:

   gcloud auth print-access-token --project=PROJECT_ID
   

2. השבתת ההגנה מפני ספירת כתובות אימייל באמצעות Identity Toolkit API:

   curl -X PATCH -d "{'emailPrivacyConfig':{'enableImprovedEmailPrivacy':false}}" \
       -H 'Authorization: Bearer ACCESS_TOKEN' \
       -H 'Content-Type: application/json' -H 'X-Goog-User-Project: PROJECT_ID' \
       "https://identitytoolkit.googleapis.com/admin/v2/projects/PROJECT_ID/config?updateMask=emailPrivacyConfig"
   

מחליפים את מה שכתוב בשדות הבאים:

• ‫ACCESS_TOKEN: אסימון הגישה שיצרתם קודם
• ‫PROJECT_ID: מזהה הפרויקט

דוגמה לתגובה עם שגיאה

אם משתמש מנסה להיכנס עם כתובת אימייל או סיסמה שגויות, או מנסה להירשם עם כתובת אימייל שכבר קיימת במערכת, Identity Platform מחזיר שגיאה שדומה לשגיאה הבאה:

{
"code": "auth/internal-error",
"message": "{\"error\":{\"code\":400,\"message\":\"INVALID_LOGIN_CREDENTIALS\",\"errors\":[{\"message\":\"INVALID_LOGIN_CREDENTIALS\",\"domain\":\"global\",\"reason\":\"invalid\"}]}}"
}