बिज़नेस ऐप के लिए Passkey: फ़िशिंग-रोधी लॉगिन का व्यावहारिक रोलआउट गाइड

सैलरी वाले दिन सुबह 8:50 बजे 40 लोगों की एक कंपनी की फ़ाइनेंस हेड sign-in नहीं कर पा रहीं, जबकि दोपहर 12 बजे तक 36 लोगों की सैलरी का रन अनुमोदित करना है। बीती रात टैक्सी में उनका फ़ोन छूट गया था।

उनके account को reset करने वाला अकेला इंसान एक IT contractor है, जो सिर्फ़ चैट पर मिलता है। जो भी उनका नाम और एक भरोसेमंद कहानी लेकर पहुँचेगा, दस मिनट में reset पा जाएगा। यह काल्पनिक दृश्य है, पर हर कंपनी में ऐसा पल आता है।

Passkey चोरी हुए password का ख़तरा जड़ से हटा देता है, पर वह असल में कितना बचाएगा, यह इस पर टिका है कि recovery का रास्ता कितना मज़बूत है। कारोबार में ज़्यादातर सेंध किसी पेचीदा hacking से नहीं, एक login से लगती है: phishing पेज पर डाला गया password, या पाँच साल पहले किसी forum पर इस्तेमाल किया password।

Passkey अब Apple, Google और Microsoft के फ़ोन, लैपटॉप और browser में पहले से मौजूद है, इसलिए तकनीक मुश्किल हिस्सा नहीं रही। मुश्किल है rollout: पहले कौन शुरू करेगा, फ़ोन खो जाए तो क्या होगा, और काउंटर पर रखे shared device का क्या किया जाए। इस लेख में passkey आसान भाषा में समझाया गया है, साथ में role के हिसाब से एक व्यावहारिक rollout योजना, और recovery व fallback के वे नियम भी, जो ज़्यादातर गाइड छोड़ देते हैं।

password और SMS कोड बार-बार क्यों फ़ेल होते हैं

Password की नाकामी की वजह इंसानी है। दर्जनों मज़बूत और अलग-अलग password किसी को याद नहीं रहते, इसलिए लोग वही password दोहराते रहते हैं। एक साइट leak होते ही हमलावर वही email और password बाक़ी हर जगह आज़माते हैं। इसे credential stuffing कहते हैं, और इसमें हुनर नहीं लगता, बस एक list और एक script चाहिए।

आँकड़े भी यही कहते हैं। Verizon की 2025 की Data Breach Investigations Report के मुताबिक़ 22% data ब्रीच में हमलावर चोरी हुए credential से घुसे, जो सबसे आम रास्ता था; उसके बाद कमज़ोरियों का फ़ायदा उठाना (20%) और फ़िशिंग (16%) रहे। 2026 के संस्करण में report के 19 साल के इतिहास में पहली बार कमज़ोरियों का फ़ायदा उठाना पहले नंबर पर आ गया। फिर भी credential की अहमियत घटी नहीं है: पहली पैठ के बाद system के अंदर घूमने और क़ीमती data तक पहुँचने के लिए हमलावर इन्हीं का इस्तेमाल करते हैं।

वन-टाइम कोड जोड़ने से मदद मिलती है, पर उतनी नहीं जितनी लोग मानते हैं:

• Phishing relay। नक़ली login page पहले password माँगता है, फिर OTP, और दोनों को उसी पल असली साइट पर भेज देता है। user ने सब कुछ "सही" किया, फिर भी फँस गया।
• SIM swap। हमलावर मोबाइल कंपनी को बहलाकर आपका नंबर अपने SIM पर चढ़वा लेता है और आपके SMS code ख़ुद पाने लगता है।
• थकान और social engineering। थका हुआ आदमी रात 11 बजे push notification पर "Approve" दबा देता है, या IT वाला बनकर फ़ोन करने वाले को code बता देता है।

तीनों की कमज़ोरी एक ही है: user के पास कुछ ऐसा है जो बहला-फुसलाकर निकलवाया जा सकता है। Passkey वही चीज़ हटा देता है।

आसान भाषा में Passkey

Passkey cryptographic keys की एक जोड़ी है, जो किसी साइट पर register करते समय बनती है। Private key आपके device पर ही रहती है, कभी बाहर नहीं जाती। Public key बिज़नेस app के पास जमा रहती है। Sign-in के वक़्त app एक बार के लिए बनी challenge भेजता है, आप fingerprint, चेहरे या screen PIN से device खोलते हैं तो device उस पर दस्तख़त कर देता है, और app public key से दस्तख़त जाँच लेता है।

इसके पीछे के मानक हैं WebAuthn (browser वाला हिस्सा) और FIDO2, इसीलिए आपको दोनों नाम दिखेंगे। Rollout के लिए बारीक़ियाँ जानना ज़रूरी नहीं, पर दो ख़ूबियाँ समझ लें तो पता चलता है कि यह इतना काम का क्यों है।

असली डोमेन से बँधा हुआ

Passkey एक ख़ास साइट के पते के लिए बनता है, और browser उसे सिर्फ़ उसी पते पर दिखाता है। नक़ली domain देखने में चाहे जितना हूबहू हो, वहाँ मेल खाने वाला कोई passkey होता ही नहीं, इसलिए टाइप करने को कुछ नहीं और चुराने को भी कुछ नहीं। "Phishing-resistant" का यही मतलब है: नक़ली साइट पहचानने का ज़िम्मा user पर नहीं रहता।

network पर कोई राज़ नहीं जाता

Server के पास ऐसा कुछ नहीं होता जो हमलावर के काम आए। बिज़नेस app का database leak भी हो जाए तो उसमें सिर्फ़ public key मिलेंगी, जो अकेले किसी काम की नहीं। इसकी तुलना leak हुई password टेबल से कीजिए, जो बाक़ी हर जगह credential stuffing की शुरुआती पूँजी बन जाती है।

Synced या device-bound: जोखिम देखकर चुनें

Passkey दो तरह के होते हैं, और पॉलिसी बनाते समय यह फ़र्क़ काम आता है।

प्रकार	Key कहाँ रहती है	ताक़त	कमज़ोर कड़ी
Synced passkey	Platform account या password manager में, व्यक्ति के अपने device-ों पर copy होती है	अपनाना आसान, फ़ोन खोने पर भी बची रहती है	उतनी ही सुरक्षित, जितना वह account जो इसे sync करता है
Device-bound passkey	एक ही physical device में, जैसे hardware security key	Key को copy या export नहीं किया जा सकता	Device खो जाए तो backup चाहिए

ज़्यादातर कर्मचारियों के लिए synced passkey व्यावहारिक चुनाव है, क्योंकि उन्हें कुछ नया साथ लेकर चलना नहीं पड़ता। Admin और जो लोग payment मंज़ूर कर सकते हैं, उनके लिए device-bound की थोड़ी-सी लागत भी वाजिब है: हर व्यक्ति के लिए दो hardware security key एक नक़ली payment के नुक़सान के सामने कुछ भी नहीं।

अपनाने के बारे में सबूत क्या कहते हैं

आप शुरुआती लोगों में नहीं हैं। इस मानक की देखरेख करने वाले FIDO Alliance ने अक्टूबर 2025 में Passkey Index जारी किया, जिसमें Amazon, Google, Microsoft और PayPal समेत नौ बड़ी service-ों का sign-in data लिया गया। इसके मुताबिक़ passkey से sign-in की सफलता दर 93% रही, जबकि दूसरे तरीक़ों की 63%; औसत sign-in समय 8.5 सेकंड रहा, जबकि दूसरे तरीक़ों में 31.२ सेकंड; और जिन कंपनियों ने passkey अपनाए, वहाँ login से जुड़ी helpdesk घटनाएँ 81% घट गईं। ये बड़ी consumer service-ों के आँकड़े हैं, इसलिए इन्हें अपनी टीम के लिए वादा नहीं, दिशा समझिए। पर दिशा साफ़ है: passkey ज़्यादा सुरक्षित भी हैं और ज़्यादा आसान भी, जो security में कम ही देखने को मिलता है।

कंपनी के भीतर आपकी सबसे मज़बूत दलील यही है। जो चीज़ आज के तरीक़े से तेज़ हो, उसे लोग ख़ुद अपना लेते हैं।

Role के हिसाब से rollout योजना

सबको एक ही सोमवार को switch न कराएँ। जहाँ चूक होने पर नुक़सान सबसे बड़ा होगा, वहाँ से शुरू कीजिए, छोटे समूह से सीखिए, फिर दायरा बढ़ाइए।

चरण 1: Admin और Finance

ये account दाम बदल सकते हैं, ग्राहकों का data export कर सकते हैं, refund अनुमोदित कर सकते हैं और बैंक की जानकारी बदल सकते हैं। यहाँ passkey enforce कीजिए, हर व्यक्ति के दो-दो register कराइए (जैसे लैपटॉप और एक hardware security key), recovery code offline रखिए, और इन role-ों के लिए SMS code बंद कर दीजिए।

चरण 2: Customer या stock data तक पहुँच वाले कर्मचारी

अगले sign-in पर passkey माँगिए, backup के तौर पर authenticator app रखिए, और 20 मिनट का एक help session कीजिए। हर हफ़्ते देखिए कितने लोग enroll हुए। "74% हो चुका" जैसा सामने दिखता आँकड़ा लोगों को काम पूरा करने की वजह दे देता है।

चरण 3: Shared device और contractor

इस चरण के लिए अलग नियम चाहिए, इसलिए अगले हिस्से में इसे अलग से लिया गया है।

चरण 4: Customer

सामान्य sign-in के बाद account page पर एक-टैप वाले विकल्प के रूप में passkey दिखाइए। Fallback के लिए email link या password रखिए, और checkout के बीच में कभी नया तरीक़ा थोपिए मत। जो customer पैसे देने आया है, उसके सामने नया login तरीक़ा नहीं आना चाहिए।

Shared counter, POS terminal और contractor

Passkey एक इंसान की पहचान कराता है। काउंटर का shared device वही चलाता है जो उस shift में होता है। इन दोनों सच्चाइयों को जुगाड़ से नहीं, सीधे सँभालना होगा।

• Shared device पर भी हर व्यक्ति को उसका अपना sign-in दीजिए। एक ही account में सबके घुसने से बेहतर है hardware security key, या device login के ऊपर छोटा staff PIN, क्योंकि तब audit log बताता है कि क्या किसने बेचा।
• काउंटर staff़ के लिए hardware security key रखिए, जहाँ floor पर फ़ोन की मनाही है। ये बिना battery और बिना pairing के चलती हैं।
• Device को भी lock रखिए। Kiosk mode, auto screen lock और managed browser उतने ही अहम हैं जितना login का तरीक़ा।
• Contractor-ों को expiry वाले account दीजिए, उसी passkey नियम और एक अंतिम तारीख़ के साथ, staff का login उधार देने के बजाय।

Recovery: पूरी व्यवस्था चलेगी या नहीं, यहीं तय होता है

शुरू करने से पहले एक सवाल का जवाब लिखकर तय कर लीजिए: "किसी का फ़ोन खो गया तो?" नीचे का फ़्लोचार्ट पूरी नीति एक पन्ने पर दिखा देता है।

1. हर व्यक्ति कम से कम दो तरीक़ों से sign-in register करे: दो passkey, या एक passkey और एक authenticator app।
2. Synced passkey आम मामला सँभाल लेते हैं। उसी platform account से sign-in किया नया फ़ोन passkey अपने साथ ले आता है।
3. Admin के recovery code print करके offline रखें, उस बैग में नहीं जिसमें hardware security key रखी है।
4. Helpdesk reset में असली जाँच हो। चैट या फ़ोन पर माँगा गया reset हमलावर का पसंदीदा दरवाज़ा है। Manager की मंज़ूरी या video call अनिवार्य कीजिए, और हर reset log कीजिए।
5. खोए हुए device को तुरंत हटाइए, user के register किए passkey की सूची से।

Recovery के रास्ते को security का हिस्सा मानिए, बग़ल का दरवाज़ा नहीं। कमज़ोर reset प्रक्रिया के साथ मज़बूत से मज़बूत passkey भी उतना ही मज़बूत है जितनी reset प्रक्रिया।

Fallback MFA और role के हिसाब से policy

कुछ समय तक fallback रखना ही पड़ेगा। उन्हें मज़बूती के क्रम में सजाइए और सबसे कमज़ोर को पहले हटाइए: passkey, फिर authenticator app (समय-आधारित code), फिर email link, और सबसे आख़िर में SMS। SMS न होने से बेहतर है, पर जिसके हाथ में अहम अधिकार हैं, उसके लिए सबसे पहले हटाने लायक़ तरीक़ा यही है।

Role	मुख्य sign-in	Backup	कभी मंज़ूर नहीं
Admin	Passkey, hardware security key बेहतर	दूसरा passkey और offline recovery code	SMS code, shared login
Finance और payroll	Passkey, hardware security key बेहतर	Authenticator app	SMS code
कर्मचारी	Synced passkey	Authenticator app	Shared login
Counter और POS	Hardware security key, या lock किए device पर निजी PIN	Supervisor override, log के साथ	पूरी shift के लिए एक account
Contractor	Expiry वाले account पर passkey	Authenticator app	उधार लिए staff़ account
Customer	वैकल्पिक passkey	Email link या password	Checkout पर ज़बरदस्ती enrollment

अपने बिज़नेस software से क्या माँगें

Rollout उतना ही कारगर होगा जितना आपका software enforce करने देगा। शुरू करने से पहले जाँच लीजिए कि आपका ERP, shop admin और POS नीचे की बातें कर पाते हैं या नहीं:

• Admin sign-in के लिए passkey, सिर्फ़ customer़-ों के लिए नहीं।
• Role के हिसाब से enforce किया गया two-step sign-in, ताकि "finance को passkey ही इस्तेमाल करना होगा" कहने पर system ख़ुद उसे लागू रखे।
• Session management: चालू session की सूची, remote sign-out और छोटा idle timeout।
• Sign-in audit log, जिसमें दिखे कि कौन, कहाँ से, किस तरीक़े से घुसा, और कौन-सा reset या नया device जुड़ा।
• हर व्यक्ति का अलग account और permission, ताकि shared device का मतलब shared पहचान न हो जाए।

कुछ platform यह सब पहले से देते हैं। मिसाल के तौर पर StoreConsole में admin passkey register कर सकते हैं और two-step sign-in enforce कर सकते हैं। आप जो भी इस्तेमाल करें, किसी और के लिए launch करने से पहले recovery flow को ख़ुद एक बार आज़माकर देख लीजिए।

Rollout अटकाने वाली पाँच ग़लतियाँ

• सबका backup बनने से पहले ही enforce कर देना, और सैलरी वाले दिन finance प्रमुख को lockout कर बैठना।
• "कभी ज़रूरत पड़ी तो" सोचकर SMS चालू छोड़ना, जिससे हमलावर सबसे कमज़ोर दरवाज़ा ही चुन लेता है।
• Helpdesk को भूल जाना, जो नए login को bypass करने का सबसे आसान रास्ता बन जाता है।
• Shared device छोड़ देना और चुपचाप उनके लिए shared password रखे रहना।
• 100% passkey हो जाने पर जीत घोषित कर देना, जबकि पुराने password अब भी चल रहे हैं। गिनिए कि कितने account अब भी password से sign-in कर सकते हैं, और उस संख्या को नीचे लाइए।

तकनीकी पृष्ठभूमि और passkey सपोर्ट करने वाली सेवाओं की सूची के लिए FIDO Alliance का passkey पेज एक निष्पक्ष और अच्छी शुरुआत है। Verizon की report Verizon के DBIR पेज पर मिल जाएगी।

अब सैलरी वाली उस सुबह पर लौटें। दो passkey register होने की वजह से finance हेड 8:55 पर अपने लैपटॉप से sign-in करती हैं और खोया फ़ोन अपनी सूची से हटा देती हैं। अगर उनके पास सिर्फ़ फ़ोन होता, तो contractor एक-बार का code देने से पहले video call और manager की मंज़ूरी माँगता, और चैट वाले अजनबी के हाथ कुछ न लगता। दोपहर 12 बजे सैलरी रन निकल जाता है, और audit log में हर क़दम दर्ज रहता है।

मुख्य बातें

• चोरी हुए credential अब भी data breach के केंद्र में हैं, और SMS या पेज में टाइप किए गए code को phishing या relay किया जा सकता है।
• Passkey असली domain से बँधा है और user के पास सौंपने लायक़ कोई राज़ नहीं होता; इसीलिए वह phishing को रोकता है।
• ज़्यादातर कर्मचारियों के लिए synced passkey, और admin, finance व counter के लिए hardware security key इस्तेमाल करें।
• जोखिम के हिसाब से rollout करें: पहले admin और finance, फिर कर्मचारी, shared device और contractor के लिए अलग नियम, और customer सबसे आख़िर में तथा optional रूप से।
• कुछ भी enforce करने से पहले recovery प्रक्रिया लिख लें, और helpdesk reset को उतनी ही सावधानी से सुरक्षित रखें जितना login को।
• ऐसा software चुनें जो role के हिसाब से passkey enforce करे और sign-in का audit log रखे।

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।