Android डेवलपर के तौर पर, आपको सुरक्षा को बेहतर बनाने, उपयोगकर्ता अनुभव को बेहतर बनाने, और डेवलपमेंट को आसान बनाने के तरीके खोजने होते हैं. Zoho, क्लाउड पर आधारित एक सॉफ़्टवेयर सुइट है. यह सुरक्षा और बेहतरीन अनुभव देने पर फ़ोकस करता है. इसने अपने OneAuth Android ऐप्लिकेशन में पासकी की सुविधा को शामिल करके, काफ़ी सुधार किए हैं.

Zoho ने 2024 में पासकी को इंटिग्रेट किया. इसके बाद, उसे लॉगिन करने की स्पीड में छह गुना तक की बढ़ोतरी मिली. साथ ही, पासकी का इस्तेमाल करने वाले लोगों की संख्या में हर महीने (एमओएम) 31% की बढ़ोतरी हुई.

इस केस स्टडी में, पुष्टि करने से जुड़ी समस्याओं को हल करने के लिए, Zoho के पासकी और Android के Credential Manager API को अपनाने के बारे में बताया गया है. इसमें तकनीकी तौर पर लागू करने की प्रोसेस के बारे में बताया गया है. साथ ही, इससे मिलने वाले असरदार नतीजों को हाइलाइट किया गया है.

पुष्टि करने से जुड़ी समस्याओं को हल करना

Zoho, उपयोगकर्ता खातों को सुरक्षित रखने के लिए, पुष्टि करने के कई तरीकों का इस्तेमाल करता है. इसमें Zoho OneAuth शामिल था. यह कई चरणों में पुष्टि (एमएफ़ए) करने का उनका अपना समाधान है. इसमें पुश नोटिफ़िकेशन, क्यूआर कोड, और समय के हिसाब से एक बार इस्तेमाल होने वाले पासवर्ड (टीओटीपी) का इस्तेमाल करके, पासवर्ड के साथ और पासवर्ड के बिना पुष्टि करने की सुविधा मिलती है. Zoho में फ़ेडरेटेड लॉगिन की सुविधा भी उपलब्ध थी. इससे सिक्योरिटी असर्शन मार्कअप लैंग्वेज (एसएएमएल) और तीसरे पक्ष की पहचान देने वाली अन्य कंपनियों के ज़रिए पुष्टि की जा सकती थी.

चुनौतियां

Zoho का मकसद, कई संगठनों की तरह ही, पुष्टि करने की सुरक्षा और उपयोगकर्ता अनुभव को बेहतर बनाना था. साथ ही, परिचालन से जुड़े कामों को कम करना था. पासकी को अपनाने से जुड़ी मुख्य चुनौतियां ये थीं:

• सुरक्षा से जुड़ी कमज़ोरियां: पासवर्ड पर आधारित पारंपरिक तरीकों से, उपयोगकर्ताओं को फ़िशिंग हमलों और पासवर्ड के गलत इस्तेमाल का खतरा बना रहता था.
• उपयोगकर्ता को होने वाली समस्याएं: पासवर्ड याद न रहने की वजह से, उपयोगकर्ता पासवर्ड भूल जाते हैं. इससे उन्हें निराशा होती है और वे पासवर्ड वापस पाने की मुश्किल प्रोसेस पर ज़्यादा निर्भर हो जाते हैं.
• कामकाज में कमियां: पासवर्ड रीसेट करने और एमएफ़ए से जुड़ी समस्याओं को हल करने में, सहायता टीम को काफ़ी समय लगता था.
• स्केल करने से जुड़ी समस्याएं: उपयोगकर्ताओं की बढ़ती संख्या की वजह से, पुष्टि करने के ज़्यादा सुरक्षित और असरदार तरीके की ज़रूरत थी.

पासवर्ड की जगह पासकी का इस्तेमाल क्यों किया जा रहा है?

Zoho के ऐप्लिकेशन में पासकी की सुविधा लागू की गई है. इससे पुष्टि करने से जुड़ी समस्याओं को हल करने में मदद मिलती है. साथ ही, बिना पासवर्ड के साइन इन करने की सुविधा मिलती है. इससे सुरक्षा और उपयोगकर्ता अनुभव बेहतर होता है. यह समाधान, फ़िशिंग से सुरक्षित ऑथेंटिकेशन, अलग-अलग डिवाइसों पर आसानी से ऐक्सेस करने के लिए क्लाउड-सिंक किए गए क्रेडेंशियल, और सुरक्षित लॉगिन के लिए बायोमेट्रिक्स (जैसे, फ़िंगरप्रिंट या चेहरे की पहचान), पिन या पैटर्न का इस्तेमाल करता है. इससे, पारंपरिक पासवर्ड से जुड़ी कमज़ोरियां और समस्याएं कम हो जाती हैं.

Credential Manager के साथ पासकी का इस्तेमाल करने से, Zoho ने लॉगिन के समय को छह गुना तक कम कर दिया. साथ ही, पासवर्ड से जुड़ी सहायता के लिए होने वाले खर्च में कटौती की. इसके अलावा, उपयोगकर्ताओं ने बड़ी संख्या में पासकी का इस्तेमाल करना शुरू कर दिया. इससे, चार महीनों में पासकी से साइन इन करने वाले उपयोगकर्ताओं की संख्या दोगुनी हो गई. साथ ही, इसमें हर महीने 31% की बढ़ोतरी हुई. Zoho के उपयोगकर्ता अब तेज़ी से और आसानी से लॉगिन कर सकते हैं. साथ ही, फ़िशिंग से बचने के लिए बेहतर सुरक्षा का फ़ायदा पा सकते हैं.

Android पर Credential Manager के साथ लागू करना

तो, Zoho ने ये नतीजे कैसे हासिल किए? उन्होंने Android के Credential Manager API का इस्तेमाल किया. यह Android पर पुष्टि करने की सुविधा लागू करने के लिए, सुझाई गई Jetpack लाइब्रेरी है.

Credential Manager, एक यूनीफ़ाइड एपीआई उपलब्ध कराता है. इससे पुष्टि करने के अलग-अलग तरीकों को आसानी से मैनेज किया जा सकता है. पासवर्ड, पासकी, और फ़ेडरेटेड लॉगिन (जैसे, 'Google से साइन इन करें') के लिए अलग-अलग एपीआई इस्तेमाल करने के बजाय, एक ही इंटरफ़ेस का इस्तेमाल किया जाता है.

Zoho में पासकी लागू करने के लिए, क्लाइंट-साइड और सर्वर-साइड, दोनों में बदलाव करने पड़े. पासकी बनाने, साइन-इन करने, और सर्वर साइड पर लागू करने की प्रोसेस के बारे में यहां पूरी जानकारी दी गई है.

पासकी बनाना

पासकी बनाने के लिए, ऐप्लिकेशन पहले Zoho के सर्वर से कॉन्फ़िगरेशन की जानकारी लेता है. इस प्रोसेस में, यूनीक तरीके से पुष्टि की जाती है. जैसे, फ़िंगरप्रिंट या चेहरे की पहचान. पुष्टि किए गए इस डेटा को requestJson स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. इसका इस्तेमाल ऐप्लिकेशन, CreatePublicKeyCredentialRequest बनाने के लिए करता है. इसके बाद, ऐप्लिकेशन credentialManager.createCredential तरीके को कॉल करता है. इससे उपयोगकर्ता को अपने डिवाइस के स्क्रीन लॉक (बायोमेट्रिक्स, फ़िंगरप्रिंट, पिन वगैरह) का इस्तेमाल करके पुष्टि करने के लिए कहा जाता है.

उपयोगकर्ता की पुष्टि हो जाने के बाद, ऐप्लिकेशन को नई पासकी के क्रेडेंशियल का डेटा मिलता है. यह डेटा, पुष्टि करने के लिए Zoho के सर्वर को वापस भेज दिया जाता है. इसके बाद, सर्वर उपयोगकर्ता के खाते से जुड़ी पासकी की जानकारी को सेव कर लेता है. इस प्रोसेस के दौरान होने वाली गड़बड़ियों या उपयोगकर्ता की ओर से रद्द किए जाने की जानकारी, ऐप्लिकेशन को मिल जाती है. साथ ही, ऐप्लिकेशन इन गड़बड़ियों को ठीक कर लेता है.

साइन-इन करें

Zoho का Android ऐप्लिकेशन, पासकी से साइन-इन करने की प्रोसेस शुरू करता है. इसके लिए, वह Zoho के बैकएंड सर्वर से साइन-इन करने के विकल्पों का अनुरोध करता है. इनमें यूनीक challenge भी शामिल है. इसके बाद, ऐप्लिकेशन इस डेटा का इस्तेमाल करके GetCredentialRequest बनाता है. इससे पता चलता है कि वह पासकी से पुष्टि करेगा. इसके बाद, यह इस अनुरोध के साथ Android CredentialManager.getCredential() एपीआई को कॉल करता है. इस कार्रवाई से, Android सिस्टम का स्टैंडर्ड इंटरफ़ेस ट्रिगर होता है. इसमें उपयोगकर्ता को अपना Zoho खाता चुनने के लिए कहा जाता है. ऐसा तब होता है, जब एक से ज़्यादा पासकी मौजूद हों. इसके बाद, उपयोगकर्ता को अपने डिवाइस पर कॉन्फ़िगर किए गए स्क्रीन लॉक (फ़िंगरप्रिंट, चेहरे की पहचान या पिन) का इस्तेमाल करके पुष्टि करनी होती है. पुष्टि हो जाने के बाद, Credential Manager, Zoho ऐप्लिकेशन को साइन किया गया एक दावा (लॉगिन का सबूत) भेजता है. ऐप्लिकेशन इस दावे को Zoho के सर्वर पर भेजता है. यह सर्वर, उपयोगकर्ता की सेव की गई सार्वजनिक पासकोड के हिसाब से हस्ताक्षर की पुष्टि करता है और चुनौती की पुष्टि करता है. इससे सुरक्षित तरीके से साइन-इन करने की प्रोसेस पूरी हो जाती है.

सर्वर-साइड इंटिग्रेशन

Zoho के बैकएंड सिस्टम पहले से ही FIDO WebAuthn के साथ काम करते थे. इसलिए, पासकी की सुविधा को चालू करने में उन्हें काफ़ी फ़ायदा मिला. इससे सर्वर-साइड पर पासकी की सुविधा को लागू करने की प्रोसेस आसान हो गई. हालांकि, पासकी की सुविधा को पूरी तरह से इंटिग्रेट करने के लिए, कुछ बदलाव अब भी ज़रूरी थे.

सबसे बड़ी चुनौती, क्रेडेंशियल सेव करने के सिस्टम को अडैप्ट करने से जुड़ी थी. पुष्टि करने के लिए Zoho के मौजूदा तरीकों में, मुख्य रूप से पासवर्ड और एफ़आईडीओ सुरक्षा कुंजियों का इस्तेमाल किया जाता था. इसके लिए, पासकी की तुलना में स्टोरेज के अलग-अलग तरीकों की ज़रूरत होती थी. पासकी, क्रिप्टोग्राफ़िक सार्वजनिक कुंजियों पर आधारित होती हैं. इस समस्या को हल करने के लिए, Zoho ने एक नया डेटाबेस स्कीमा लागू किया है. इसे खास तौर पर, WebAuthn प्रोटोकॉल के मुताबिक पासकी की सार्वजनिक कुंजियों और उनसे जुड़े डेटा को सुरक्षित तरीके से सेव करने के लिए डिज़ाइन किया गया है. इस नए सिस्टम को लुकअप मैकेनिज़्म के साथ बनाया गया है. इससे उपयोगकर्ता और डिवाइस की जानकारी के आधार पर क्रेडेंशियल की पुष्टि की जा सकती है और उन्हें वापस पाया जा सकता है. साथ ही, यह पुराने पुष्टि करने के तरीकों के साथ काम करता है.

सर्वर-साइड में किए गए एक और बदलाव में, Android डिवाइसों से मिले अनुरोधों को हैंडल करने की सुविधा लागू करना शामिल है. Android ऐप्लिकेशन से पासकी के अनुरोध, यूनीक ओरिजिन फ़ॉर्मैट (android:apk-key-hash:example) का इस्तेमाल करते हैं. यह यूआरआई पर आधारित फ़ॉर्मैट (https://example.com/app) का इस्तेमाल करने वाले स्टैंडर्ड वेब ओरिजिन से अलग होता है. इस फ़ॉर्मैट को सही तरीके से पार्स करने, ऐप्लिकेशन के साइनिंग सर्टिफ़िकेट के SHA-256 फ़िंगरप्रिंट हैश को निकालने, और पहले से रजिस्टर की गई सूची के हिसाब से इसकी पुष्टि करने के लिए, सर्वर लॉजिक को अपडेट करना ज़रूरी था. पुष्टि करने के इस चरण से यह पक्का किया जाता है कि पुष्टि करने के अनुरोध, Zoho के Android ऐप्लिकेशन से ही किए गए हों. साथ ही, इससे फ़िशिंग हमलों से सुरक्षा मिलती है.

इस कोड स्निपेट में बताया गया है कि सर्वर, 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 के UX से जुड़े सुझावों के आधार पर, 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 Password Manager की पुष्टि करने की प्रोसेस में, सार्वजनिक डोमेन का ऐक्सेस ज़रूरी होता है. इससे, भरोसा करने वाली पार्टी (आरपी) के डोमेन की पुष्टि की जा सकती है. हालांकि, Zoho के इंटरनल टेस्टिंग एनवायरमेंट में, सार्वजनिक इंटरनेट का ऐक्सेस नहीं था. इस वजह से, पुष्टि की प्रक्रिया पूरी नहीं हो सकी. साथ ही, पासकी की पुष्टि करने की टेस्टिंग भी पूरी नहीं हो सकी. इस समस्या को हल करने के लिए, Zoho ने सार्वजनिक तौर पर ऐक्सेस किया जा सकने वाला टेस्ट एनवायरमेंट बनाया. इसमें ऐसेट लिंक फ़ाइल और डोमेन की पुष्टि करने के साथ-साथ, एक अस्थायी सर्वर को होस्ट करना शामिल था.

Zoho के सार्वजनिक टेस्ट एनवायरमेंट में इस्तेमाल की गई assetlinks.json फ़ाइल के इस उदाहरण में, पासकोड की पुष्टि करने के लिए, भरोसेमंद पार्टी के डोमेन को बताए गए 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 ने FIDO2 JSON स्ट्रक्चर के मुताबिक अनुरोधों को सही तरीके से जनरेट और प्रोसेस करने के लिए, कुछ बदलाव किए हैं.

सर्वर के इस अपडेट में, कई तकनीकी बदलाव किए गए हैं:

1. कन्वर्ज़न को कोड में बदलना: सर्वर, Base64 यूआरएल एन्कोडिंग को स्टैंडर्ड Base64 एन्कोडिंग में बदलता है. इसका इस्तेमाल आम तौर पर WebAuthn में क्रेडेंशियल आईडी जैसे फ़ील्ड के लिए किया जाता है. इसके बाद, सर्वर काम का डेटा सेव करता है. नीचे दिए गए स्निपेट में दिखाया गया है कि rawId को स्टैंडर्ड Base64 में कैसे कोड में बदला जा सकता है:

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

2. ट्रांसपोर्ट की सूची का फ़ॉर्मैट: डेटा को लगातार प्रोसेस करने के लिए, सर्वर लॉजिक, ट्रांसपोर्ट के तरीकों की सूचियों को JSON ऐरे के तौर पर मैनेज करता है. जैसे, यूएसबी, एनएफ़सी, और ब्लूटूथ. इनसे यह पता चलता है कि पुष्टि करने वाले व्यक्ति ने कैसे कम्यूनिकेट किया.

3. क्लाइंट डेटा अलाइनमेंट: Zoho की टीम ने, server encodes और decode the clientDataJson फ़ील्ड के तरीके में बदलाव किया है. इससे यह पक्का होता है कि डेटा स्ट्रक्चर, 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 के वेब accounts पेज पर जाएं.

इस तरीके से यह पक्का किया गया कि पासकी सेट अप करने और इस्तेमाल करने की प्रोसेस, उन प्लैटफ़ॉर्म पर उपलब्ध हो जिन पर उपयोगकर्ता पहले से ही काम कर रहे हैं. इससे कोई फ़र्क़ नहीं पड़ता कि एडमिन ने पासकी का इस्तेमाल करना ज़रूरी किया है या उपयोगकर्ता ने इसे चुना है. हमारी पासकी के उपयोगकर्ता अनुभव से जुड़ी गाइड पढ़कर, पासकी की मदद से पुष्टि करने के लिए आसान यूज़र फ़्लो बनाने के बारे में ज़्यादा जानें.

डेवलपर की स्पीड और इंटिग्रेशन की क्षमता पर असर

क्रेडेंशियल मैनेजर, एक यूनिफ़ाइड एपीआई के तौर पर काम करता है. इससे डेवलपर की प्रॉडक्टिविटी को बेहतर बनाने में भी मदद मिली है. ऐसा, साइन-इन करने के पुराने तरीकों की तुलना में हुआ है. इससे, पुष्टि करने के कई तरीकों और एपीआई को अलग-अलग मैनेज करने की जटिलता कम हो गई. इससे इंटिग्रेशन में लगने वाला समय, महीनों से घटकर हफ़्तों में आ गया. साथ ही, लागू करने से जुड़ी गड़बड़ियां भी कम हो गईं. इससे साइन-इन करने की प्रोसेस आसान हो गई और विश्वसनीयता बेहतर हुई.

Credential Manager के साथ पासकी लागू करने से, Zoho को हर मामले में काफ़ी सुधार देखने को मिले. साथ ही, इन सुधारों को मेज़र भी किया जा सका:

• पहले की तुलना में काफ़ी तेज़
  • पासवर्ड से पुष्टि करने के पारंपरिक तरीके की तुलना में, दो गुना तेज़ी से लॉगिन किया जा सकता है.
  • ईमेल या एसएमएस पर मिले ओटीपी से पुष्टि करने के लिए, उपयोगकर्ता नाम या मोबाइल नंबर का इस्तेमाल करने की तुलना में, चार गुना तेज़ी से लॉगिन किया जा सकता है.
  • उपयोगकर्ता नाम, पासवर्ड, और एसएमएस या Authenticator ऐप्लिकेशन से ओटीपी की पुष्टि करने की तुलना में, छह गुना तेज़ी से लॉगिन किया जा सकता है.
• सहायता से जुड़ी लागत में कमी
  • पासवर्ड से जुड़े सहायता अनुरोधों में कमी आई है. खास तौर पर, उन अनुरोधों में जिनमें पासवर्ड याद न होने की समस्या बताई गई थी.
  • एसएमएस पर आधारित दो चरणों वाली पुष्टि से जुड़ी लागत कम होती है, क्योंकि मौजूदा उपयोगकर्ता सीधे तौर पर पासकी का इस्तेमाल शुरू कर सकते हैं.
• उपयोगकर्ता के लिए आसान और बेहतर सुरक्षा:
  • सिर्फ़ चार महीनों में, पासकी से साइन इन करने वालों की संख्या दोगुनी हो गई. इससे पता चलता है कि लोगों ने इसे काफ़ी पसंद किया है.
  • पासकी पर माइग्रेट करने वाले उपयोगकर्ताओं को, फ़िशिंग और पासवर्ड के गलत इस्तेमाल से जुड़े सामान्य खतरों से पूरी सुरक्षा मिलती है.
  • हर महीने 31% की बढ़ोतरी के साथ, ज़्यादा से ज़्यादा लोग हर दिन फ़िशिंग और सिम स्वैप जैसी कमज़ोरियों से बेहतर सुरक्षा पा रहे हैं.

सबसे सही तरीके और सुझाव

Android पर पासकी को सही तरीके से लागू करने के लिए, डेवलपर को इन सबसे सही तरीकों को ध्यान में रखना चाहिए:

• Android के Credential Manager API का इस्तेमाल करें:
  • Credential Manager की मदद से, क्रेडेंशियल आसानी से वापस पाए जा सकते हैं. इससे डेवलपर को कम मेहनत करनी पड़ती है. साथ ही, पुष्टि करने का एक जैसा अनुभव मिलता है.
  • यह एक ही इंटरफ़ेस में पासवर्ड, पासकी, और फ़ेडरेटेड लॉगिन फ़्लो को मैनेज करता है.
• FIDO की पुष्टि करने वाले अन्य समाधानों से माइग्रेट करते समय, डेटा एन्कोडिंग में एकरूपता बनाए रखें:
  • FIDO की पुष्टि करने वाले अन्य समाधानों, जैसे कि FIDO सिक्योरिटी की से माइग्रेट करते समय, पक्का करें कि सभी इनपुट/आउटपुट के लिए एक जैसा फ़ॉर्मैट इस्तेमाल किया गया हो.
• गड़बड़ी ठीक करने और लॉगिंग की प्रोसेस को ऑप्टिमाइज़ करें:
  • उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, गड़बड़ी ठीक करने की सुविधा लागू करें.
  • स्थानीय भाषा में गड़बड़ी के मैसेज दिखाएं. साथ ही, अचानक होने वाली गड़बड़ियों को ठीक करने के लिए, ज़्यादा जानकारी वाले लॉग का इस्तेमाल करें.
• उपयोगकर्ताओं को पासकी वापस पाने के विकल्पों के बारे में जानकारी दें:
  • उपयोगकर्ताओं को डेटा वापस पाने के विकल्पों के बारे में पहले से जानकारी देकर, उन्हें लॉकआउट होने से बचाएं.
• उपयोगकर्ता मेट्रिक और लोगों के सुझाव या राय पर नज़र रखें:
  • उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, उपयोगकर्ता के जुड़ाव, पासकी अपनाने की दरों, और लॉगिन की सफलता की दरों को ट्रैक करें.
  • कन्वर्ज़न और ऐप्लिकेशन का इस्तेमाल जारी रखने वाले लोगों की संख्या बढ़ाने के लिए, पुष्टि करने के अलग-अलग फ़्लो पर A/B टेस्टिंग करें.

पासकी और Android Credential Manager API, दोनों मिलकर पुष्टि करने का एक बेहतर और एक जैसा समाधान उपलब्ध कराते हैं. इससे सुरक्षा को बेहतर बनाने के साथ-साथ, उपयोगकर्ता अनुभव को आसान बनाया जा सकता है. पासकी की मदद से, फ़िशिंग के जोखिम, क्रेडेंशियल की चोरी, और बिना अनुमति के ऐक्सेस किए जाने के जोखिम को काफ़ी हद तक कम किया जा सकता है. हम डेवलपर को अपने ऐप्लिकेशन में इस सुविधा को आज़माने और अपने उपयोगकर्ताओं को सबसे सुरक्षित पुष्टि की सुविधा देने के लिए प्रोत्साहित करते हैं.

पासकी और Credential Manager का इस्तेमाल शुरू करना

हमारे सार्वजनिक सैंपल कोड का इस्तेमाल करके, Android पर पासकी और Credential Manager को आज़माएं.

अगर आपका कोई सवाल है या आपको कोई समस्या आ रही है, तो Android क्रेडेंशियल से जुड़ी समस्याओं को ट्रैक करने वाले टूल के ज़रिए हमसे संपर्क करें.