אימות מאובטח של משתמשים

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

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

תיבת דו-שיח של אימות ביומטרי

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

איך זה עוזר לצמצם את ההונאות ואת גניבות הטלפונים

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

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

הטמעה

1. חשוב לוודא שספריית androidx.biometric כלולה.
2. כוללים את תיבת הדו-שיח של הכניסה הביומטרית בפעילות או בקטע שמכילים את הלוגיקה שרוצים שהמשתמש יאומת.

Kotlin

private var executor: Executor? = null
private var biometricPrompt: BiometricPrompt? = null
private var promptInfo: BiometricPrompt.PromptInfo? = null

fun onCreate(savedInstanceState: Bundle?) {
  super.onCreate(savedInstanceState)
  setContentView(R.layout.activity_login)
  executor = ContextCompat.getMainExecutor(this)
  biometricPrompt = BiometricPrompt(this@MainActivity,
    executor, object : AuthenticationCallback() {
      fun onAuthenticationError(
        errorCode: Int,
        @NonNull errString: CharSequence
      ) {
        super.onAuthenticationError(errorCode, errString)
        Toast.makeText(
          getApplicationContext(),
          "Authentication error: $errString", Toast.LENGTH_SHORT
        )
          .show()
      }

      fun onAuthenticationSucceeded(
        @NonNull result: BiometricPrompt.AuthenticationResult?
      ) {
        super.onAuthenticationSucceeded(result)
        Toast.makeText(
          getApplicationContext(),
          "Authentication succeeded!", Toast.LENGTH_SHORT
        ).show()
      }

      fun onAuthenticationFailed() {
        super.onAuthenticationFailed()
        Toast.makeText(
          getApplicationContext(), "Authentication failed",
          Toast.LENGTH_SHORT
        )
          .show()
      }
    })
  promptInfo = Builder()
    .setTitle("Biometric login for my app")
    .setSubtitle("Log in using your biometric credential")
    .setNegativeButtonText("Use account password")
    .build()

  // Prompt appears when user clicks "Log in".
  // Consider integrating with the keystore to unlock cryptographic operations,
  // if needed by your app.
  val biometricLoginButton: Button = findViewById(R.id.biometric_login)
  biometricLoginButton.setOnClickListener { view ->
    biometricPrompt.authenticate(
      promptInfo
    )
  }
}

Java

private Executor executor;
private BiometricPrompt biometricPrompt;
private BiometricPrompt.PromptInfo promptInfo;

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_login);
    executor = ContextCompat.getMainExecutor(this);
    biometricPrompt = new BiometricPrompt(MainActivity.this,
            executor, new BiometricPrompt.AuthenticationCallback() {
        @Override
        public void onAuthenticationError(int errorCode,
                @NonNull CharSequence errString) {
            super.onAuthenticationError(errorCode, errString);
            Toast.makeText(getApplicationContext(),
                "Authentication error: " + errString, Toast.LENGTH_SHORT)
                .show();
        }

        @Override
        public void onAuthenticationSucceeded(
                @NonNull BiometricPrompt.AuthenticationResult result) {
            super.onAuthenticationSucceeded(result);
            Toast.makeText(getApplicationContext(),
                "Authentication succeeded!", Toast.LENGTH_SHORT).show();
        }

        @Override
        public void onAuthenticationFailed() {
            super.onAuthenticationFailed();
            Toast.makeText(getApplicationContext(), "Authentication failed",
                Toast.LENGTH_SHORT)
                .show();
        }
    });

    promptInfo = new BiometricPrompt.PromptInfo.Builder()
            .setTitle("Biometric login for my app")
            .setSubtitle("Log in using your biometric credential")
            .setNegativeButtonText("Use account password")
            .build();

    // Prompt appears when the user clicks "Log in".
    // Consider integrating with the keystore to unlock cryptographic operations,
    // if needed by your app.
    Button biometricLoginButton = findViewById(R.id.biometric_login);
    biometricLoginButton.setOnClickListener(view -> {
            biometricPrompt.authenticate(promptInfo);
    });
}

שיטות מומלצות

מומלץ להתחיל עם ה-codelab כדי לקבל מידע נוסף על ביומטריה.

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

מידע נוסף על אימות ביומטרי

מפתחות גישה

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

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

ב-Android, יש תמיכה במפתחות גישה באמצעות ספריית Jetpack של Credential Manager, שמאחדת את שיטות האימות העיקריות, כולל מפתחות גישה, סיסמאות וכניסה מאוחדת (כמו כניסה באמצעות חשבון Google).

איך זה עוזר לצמצם את הסיכון להונאה

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

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

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

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

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

מידע נוסף זמין במאמר בנושא אבטחת מפתחות גישה במנהל הסיסמאות של Google.

הטמעה

מפתחות גישה נתמכים במכשירים עם Android מגרסה 9 (רמת API‏ 28) ואילך. החל מ-Android 4.4, יש תמיכה בסיסמאות ובכניסה באמצעות חשבון Google. כדי להתחיל להשתמש במפתחות גישה, פועלים לפי השלבים הבאים:

1. כדי להבין איך להטמיע מפתחות גישה, אפשר להיעזר בסדנת התכנות בנושא Credential Manager.
2. מעיינים בהנחיות לעיצוב חוויית משתמש עם מפתחות גישה. במסמך הזה מוסבר אילו תהליכים מומלצים לתרחיש השימוש שלכם.
3. כדאי לעיין במדריך לניהול פרטי הכניסה.
4. מתכננים את ההטמעה של מנהל האישורים ומפתחות הגישה באפליקציה. מתכננים להוסיף תמיכה ב-Digital Asset Links.

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

איפוס מאובטח של החשבון

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

ריכזנו כאן כמה שיטות מומלצות נפוצות שאפשר לשלב בתהליך האיפוס של האפליקציה:

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

SMS Retriever API

‫SMS Retriever API מאפשר לכם לבצע אימות משתמשים שמבוסס על SMS באפליקציית Android שלכם באופן אוטומטי. כך המשתמש לא יצטרך להקליד קודי אימות באופן ידני. בנוסף, ה-API הזה לא מבקש מהמשתמש הרשאות נוספות לאפליקציה, שעלולות להיות מסוכנות, כמו RECEIVE_SMS או READ_SMS. עם זאת, לא מומלץ להשתמש ב-SMS כאימות המשתמש היחיד כדי להגן על המכשיר מפני גישה מקומית לא מורשית.

איך זה עוזר לצמצם את הסיכון להונאה

חלק מהמשתמשים משתמשים בקודים ב-SMS כגורם האימות היחיד שלהם, מה שמאפשר גישה קלה להונאה.

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

הטמעה

ההטמעה של SMS Retriever API כוללת שני חלקים: Android ושרת.

‫Android: (מדריך)

1. מקבלים את מספר הטלפון של המשתמש.
2. מפעילים את לקוח SMS Retriever.
3. שולחים את מספר הטלפון לשרת.
4. קבלת הודעות אימות.
5. שולחים את ה-OTP לשרת.

שרת: (מדריך)

1. יוצרים הודעת אימות.
2. שולחים את הודעת האימות באמצעות SMS.
3. מאמתים את ה-OTP כשמקבלים אותו.

שיטות מומלצות

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

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

הערה: ה-API הזה לא מספק הגנה מפני כל וקטורי האיומים, כמו שיבוט כרטיס SIM.

מידע נוסף

כדי לקרוא עוד על שיטות מומלצות, אפשר לעיין במשאבים הבאים:

• המסמכים שלנו בנושא אבטחה ב-Android
• המסמכים בנושא Play Integrity API
• שינויים ב-Android 15
• שיטות מומלצות למניעת שיחות הונאה מ-Monzo Bank