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

מאז שילוב מפתחות הגישה בשנת 2024, חברת Zoho השיגה מהירויות כניסה מהירות פי 6 בהשוואה לשיטות קודמות, וגידול של 31% בשימוש במפתחות גישה מחודש לחודש.

במקרה לדוגמה הזה נבחן השימוש של Zoho במפתחות גישה ובCredential Manager API של Android כדי לפתור בעיות שקשורות לאימות. הוא כולל פירוט של תהליך ההטמעה הטכנית ומדגיש את התוצאות המשמעותיות.

איך מתמודדים עם אתגרי אימות

‫Zoho משתמשת בשילוב של שיטות אימות כדי להגן על חשבונות משתמשים. זה כלל את Zoho OneAuth, פתרון האימות הרב-שלבי (MFA) שלהם, שתמך באימות באמצעות סיסמה וגם באימות ללא סיסמה באמצעות הודעות פוש, קודי QR וסיסמאות חד-פעמיות מבוססות-זמן (TOTP). בנוסף, Zoho תמכה בכניסות מאוחדות, שמאפשרות אימות באמצעות Security Assertion Markup Language ‏ (SAML) וספקי זהויות אחרים של צד שלישי.

אתגרים

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

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

למה כדאי לעבור למפתחות גישה?

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

בעקבות הטמעת מפתחות גישה באמצעות Credential Manager, חברת Zoho קיצרה את זמני הכניסה עד פי 6, צמצמה את עלויות התמיכה שקשורות לסיסמאות ונהנתה מאימוץ נרחב של מפתחות הגישה על ידי המשתמשים – מספר הכניסות באמצעות מפתחות גישה הוכפל תוך 4 חודשים, עם גידול של 31% מדי חודש. משתמשי Zoho יכולים עכשיו ליהנות מכניסות מהירות ופשוטות יותר ומאבטחה עמידה בפני פישינג.

הטמעה באמצעות Credential Manager ב-Android

אז איך Zoho השיגה את התוצאות האלה? הם השתמשו ב-Credential Manager API של Android, ספריית Jetpack המומלצת להטמעת אימות ב-Android.

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

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

יצירת מפתח גישה

כדי ליצור מפתח גישה, האפליקציה מאחזרת קודם את פרטי ההגדרה מהשרת של Zoho. התהליך הזה כולל אימות ייחודי, כמו טביעת אצבע או זיהוי פנים. נתוני האימות האלה, שמעוצבים כמחרוזת requestJson, משמשים את האפליקציה ליצירת CreatePublicKeyCredentialRequest. לאחר מכן האפליקציה קוראת לשיטה credentialManager.createCredential, שמציגה למשתמש בקשה לבצע אימות באמצעות השיטה לביטול הנעילה של המכשיר (נתונים ביומטריים, טביעת אצבע, קוד אימות וכו').

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

כניסה

אפליקציית Zoho ל-Android מתחילה את תהליך הכניסה באמצעות מפתח גישה על ידי שליחת בקשה לאפשרויות כניסה, כולל challenge ייחודי, משרת הקצה העורפי של Zoho. לאחר מכן, האפליקציה משתמשת בנתונים האלה כדי ליצור GetCredentialRequest, שמציין שהיא תאומת באמצעות מפתח גישה. לאחר מכן, הוא מפעיל את Android CredentialManager.getCredential() API עם הבקשה הזו. הפעולה הזו מפעילה ממשק מערכת סטנדרטי של Android, ומבקשת מהמשתמש לבחור את חשבון Zoho שלו (אם קיימים כמה מפתחות גישה) ולאמת את עצמו באמצעות שיטת פתיחת הנעילה שהוגדרה במכשיר (טביעת אצבע, סריקת פנים או קוד אימות). אחרי אימות מוצלח, Credential Manager מחזיר טענה חתומה (הוכחת כניסה) לאפליקציית Zoho. האפליקציה מעבירה את הטענה הזו לשרת של Zoho, שמאמת את החתימה מול המפתח הציבורי המאוחסן של המשתמש ומאמת את האתגר, וכך משלים את תהליך הכניסה המאובטח.

הטמעה בצד השרת

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

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

שינוי נוסף בצד השרת כלל הטמעה של היכולת לטפל בבקשות ממכשירי Android. בקשות למפתחות גישה שמקורן באפליקציות ל-Android משתמשות בפורמט מקור ייחודי (android:apk-key-hash:example) ששונה ממקורות אינטרנט רגילים שמשתמשים בפורמט מבוסס URI‏ (https://example.com/app). היה צורך לעדכן את לוגיקת השרת כדי לנתח את הפורמט הזה בצורה נכונה, לחלץ את גיבוב טביעת האצבע SHA-256 של אישור החתימה של האפליקציה ולאמת אותו מול רשימה רשומה מראש. שלב האימות הזה מבטיח שבקשות האימות אכן מגיעות מאפליקציית Android של Zoho, ומגן מפני התקפות פישינג.

בקטע הקוד הבא אפשר לראות איך השרת בודק את פורמט המקור הספציפי ל-Android ומאמת את הגיבוב של האישור:

val origin: String = clientData.getString("origin")

if (origin.startsWith("android:apk-key-hash:")) { 
    val originSplit: List<String> = origin.split(":")
    if (originSplit.size > 3) {
               val androidOriginHashDecoded: ByteArray = Base64.getDecoder().decode(originSplit[3])

                if (!androidOriginHashDecoded.contentEquals(oneAuthSha256FingerPrint)) {
            throw IAMException(IAMErrorCode.WEBAUTH003)
        }
    } else {
        // Optional: Handle the case where the origin string is malformed    }
}

טיפול בשגיאות

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

בדוגמת הקוד הזו אפשר לראות איך Zoho טיפלו בשגיאות הנפוצות ביותר ביצירת מפתחות גישה:

private fun handleFailure(e: CreateCredentialException) {
    val msg = when (e) {
        is CreateCredentialCancellationException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_CANCELLED", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "The operation was canceled by the user."
        }
        is CreateCredentialInterruptedException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_INTERRUPTED", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "Passkey setup was interrupted. Please try again."
        }
        is CreateCredentialProviderConfigurationException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_PROVIDER_MISCONFIGURED", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "Credential provider misconfigured. Contact support."
        }
        is CreateCredentialUnknownException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_UNKNOWN_ERROR", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "An unknown error occurred during Passkey setup."
        }
        is CreatePublicKeyCredentialDomException -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_WEB_AUTHN_ERROR", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "Passkey creation failed: ${e.domError}"
        }
        else -> {
            Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_FAILED", GROUP_NAME)
            Analytics.addNonFatalException(e)
            "An unexpected error occurred. Please try again."
        }
    }
}

בדיקת מפתחות גישה בסביבות אינטראנט

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

בדוגמה הזו מקובץ assetlinks.json שמשמש בסביבת הבדיקה הציבורית של Zoho, אפשר לראות איך לשייך את הדומיין של הצד המסתמך לאפליקציית Android שצוינה לצורך אימות מפתח הגישה.

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.zoho.accounts.oneauth",
            "sha256_cert_fingerprints": [
                "SHA_HEX_VALUE" 
            ]
        }
    }
]

שילוב עם שרת FIDO קיים

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

העדכון הזה של השרת כלל כמה שינויים טכניים ספציפיים:

1. המרת קידוד: השרת ממיר את קידוד כתובת ה-URL ב-Base64 (שמשמש בדרך כלל ב-WebAuthn לשדות כמו מזהי אישורים) לקידוד Base64 רגיל לפני שהוא מאחסן את הנתונים הרלוונטיים. בקטע הקוד הבא אפשר לראות איך אפשר לקודד rawId ל-Base64 רגיל:

// Convert rawId bytes to a standard Base64 encoded string for storage
val base64RawId: String = Base64.getEncoder().encodeToString(rawId.toByteArray())

2. פורמט רשימת אמצעי התקשורת: כדי להבטיח עיבוד עקבי של הנתונים, הלוגיקה של השרת מטפלת ברשימות של מנגנוני תקשורת (כמו USB,‏ NFC ו-Bluetooth, שמציינים איך אמצעי האימות מתקשר) כמערכי JSON.

3. התאמה של נתוני הלקוח: צוות Zoho שינה את האופן שבו השרת מקודד ומפענח את השדה clientDataJson. כך מבטיחים שמבנה הנתונים תואם בדיוק לציפיות של ממשקי ה-API הפנימיים הקיימים של Zoho. בדוגמה הבאה אפשר לראות חלק מהלוגיקה של ההמרה שמוחלת על נתוני הלקוח לפני שהשרת מעבד אותם:

private fun convertForServer(type: String): String {
    val clientDataBytes = BaseEncoding.base64().decode(type)
    val clientDataJson = JSONObject(String(clientDataBytes, StandardCharsets.UTF_8))
    val clientJson = JSONObject()
    val challengeFromJson = clientDataJson.getString("challenge")
    // 'challenge' is a technical identifier/token, not localizable text.
    clientJson.put("challenge", BaseEncoding.base64Url()
        .encode(challengeFromJson.toByteArray(StandardCharsets.UTF_8))) 

    clientJson.put("origin", clientDataJson.getString("origin"))
    clientJson.put("type", clientDataJson.getString("type"))
    clientJson.put("androidPackageName", clientDataJson.getString("androidPackageName"))
    return BaseEncoding.base64().encode(clientJson.toString().toByteArray())
}

הנחיות למשתמשים והעדפות אימות

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

ב-Zoho הבינו שלארגונים יש צרכי אבטחה שונים. כדי להתאים את עצמה לדרישה הזו, Zoho הטמיעה:

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

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

• הגדרה פשוטה: הגדרת מפתח הגישה המשולב של Zoho מתבצעת ישירות באפליקציית Zoho OneAuth לנייד (זמינה ל-Android ול-iOS). המשתמשים יכולים להגדיר את מפתחות הגישה שלהם באפליקציה בכל שלב, וכך להקל על המעבר.
• גישה עקבית: הטמענו תמיכה במפתחות גישה בנקודות מגע מרכזיות עם המשתמשים, כדי להבטיח שהם יוכלו להירשם ולבצע אימות באמצעות מפתחות גישה דרך:
• אפליקציית Zoho OneAuth לנייד (Android ו-iOS);
• בדף החשבונות שלהם ב-Zoho באינטרנט.

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

ההשפעה על מהירות הפיתוח והיעילות של השילוב

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

הטמעת מפתחות גישה באמצעות Credential Manager עזרה ל-Zoho להשיג שיפורים משמעותיים ומדידים בכל התחומים:

• שיפורים משמעותיים במהירות
  • כניסה לחשבון מהירה פי 2 בהשוואה לאימות סיסמה רגיל.
  • הכניסה מהירה פי 4 בהשוואה לכניסה באמצעות שם משתמש או מספר טלפון עם אימות באמצעות סיסמה חד-פעמית (OTP) באימייל או ב-SMS.
  • כניסה לחשבון מהירה פי 6 בהשוואה לאימות באמצעות שם משתמש, סיסמה ו-OTP ב-SMS או באפליקציית אימות.
• הפחתת עלויות התמיכה
  • פחות בקשות תמיכה שקשורות לסיסמאות, במיוחד לגבי סיסמאות שנשכחו.
  • עלויות נמוכות יותר שקשורות לאימות דו-שלבי מבוסס-SMS, כי משתמשים קיימים יכולים להצטרף ישירות באמצעות מפתחות גישה.
• שיעורי אימוץ גבוהים בקרב המשתמשים ואבטחה משופרת:
  • מספר הכניסות באמצעות מפתחות גישה הוכפל תוך 4 חודשים בלבד, מה שמעיד על רמת אימוץ גבוהה בקרב המשתמשים.
  • משתמשים שעוברים למפתחות גישה מוגנים באופן מלא מפני איומים נפוצים של פישינג ופריצה לסיסמאות.
  • עם עלייה של 31% בשיעור האימוץ מחודש לחודש, יותר משתמשים נהנים מדי יום מאבטחה משופרת מפני פגיעויות כמו פישינג והחלפת כרטיסי SIM.

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

כדי להטמיע בהצלחה מפתחות גישה ב-Android, מפתחים צריכים לפעול לפי השיטות המומלצות הבאות:

• שימוש ב-Credential Manager API של Android:
  • Credential Manager מפשט את אחזור פרטי הכניסה, מצמצם את המאמץ של המפתחים ומבטיח חוויית אימות אחידה.
  • מטפל בסיסמאות, במפתחות גישה ובתהליכי יצירת זהות מאוחדת בממשק יחיד.
• הקפידו על עקביות בקידוד הנתונים במהלך המעבר מפתרונות אימות אחרים של FIDO:
  • חשוב לוודא שאתם מטפלים בפורמט עקבי לכל הקלט והפלט במהלך המעבר מפתרונות אימות אחרים של FIDO, כמו מפתחות אבטחה של FIDO.
• אופטימיזציה של טיפול בשגיאות ורישום ביומן:
  • הטמיעו טיפול חזק בשגיאות כדי לספק חוויית משתמש חלקה.
  • כדאי לספק הודעות שגיאה מותאמות לשפה המקומית ולהשתמש ביומנים מפורטים כדי לנפות באגים ולפתור כשלים לא צפויים.
• הדרכת משתמשים לגבי אפשרויות לשחזור מפתחות גישה:
  • כדי למנוע מצבים שבהם המשתמשים ננעלים מחוץ לחשבון, כדאי להציג להם באופן יזום את אפשרויות השחזור.
• מעקב אחר מדדי אימוץ ומשוב ממשתמשים:
  • כדי להמשיך לשפר את חוויית המשתמש, כדאי לעקוב אחרי מדדי המעורבות של המשתמשים, שיעורי האימוץ של מפתחות הגישה ושיעורי ההצלחה של הכניסה לחשבון.
  • כדאי לבצע בדיקות A/B בתהליכי אימות שונים כדי לשפר את שיעורי ההמרה והשימור.

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

איך מתחילים להשתמש במפתחות גישה וב-Credential Manager

כדאי לנסות את מפתחות הגישה ואת Credential Manager ב-Android באמצעות קוד הדוגמה הציבורי שלנו.

אם יש לכם שאלות או בעיות, אתם יכולים לשתף אותן איתנו באמצעות כלי המעקב אחר בעיות שקשורות לאישורים ב-Android.