Zoho משיגה כניסות מהירות פי 6 באמצעות שילוב של מפתח גישה ו-Credential Manager

בתור מפתחים ל-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 ומגן מפני התקפות פישינג.

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

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.