लेखक: 
Research updated: 17 October 2026. जब phone पर लगातार login approval notifications आने लगें, तो यह कभी MFA Fatigue attack का संकेत हो सकता है। कर्मचारियों, स्कूलों और छोटे businesses के लिए इसका अर्थ और defence समझना जरूरी है।
MFA Fatigue या Push Bombing किसे कहते हैं
MFA का अर्थ है password के अतिरिक्त किसी दूसरे प्रमाण से login verify करना। Authenticator app में user के phone पर approval notification आ सकती है। अगर attacker को username और password मिल जाए तो वह बार-बार sign-in attempt कर सकता है जिससे लगातार prompts दिखने लगें। कई alerts से परेशान व्यक्ति कभी गलती से ‘Approve’ दबा सकता है। इसी social engineering technique को MFA fatigue या push bombing कहते हैं। इसका अर्थ यह नहीं कि MFA बेकार है; बल्कि यह बताता है कि user-friendly approval design और stronger authentication दोनों जरूरी हैं।
Attacker के पास अक्सर क्या जानकारी होती है
इस तरह के incident की शुरुआत कई बार reused password, phishing website या पुराने credential leak से हो सकती है। Attacker को target का password मालूम हो तो login system दूसरे factor की मांग करेगा। वही notification user के genuine phone पर पहुँच सकती है। अचानक कई approval requests दिखें तो इसे सिर्फ application bug न समझें। यह भी संभव है कि कोई व्यक्ति भूलवश दूसरे device से login कर रहा हो, इसलिए verification के बिना अंतिम निष्कर्ष निकालना उचित नहीं।
‘Approve’ दबाने की गलती कैसे होती है
रात में सोते समय alerts आना, किसी जरूरी office काम के बीच बार-बार popup दिखना या caller का fake IT administrator बनकर approval मांगना social engineering के सामान्य रूप हैं। Threat actor यह कह सकता है कि ‘system update है, बस एक बार accept कर दीजिए’। Employee prompt को रोकने के लिए स्वीकृति दे दे तो unwanted session खुल सकता है। स्पष्ट policy होनी चाहिए: अपनी ओर से login शुरू नहीं किया है तो request approve नहीं करनी है, चाहे caller कितना भी भरोसेमंद लगे।
Number Matching के पीछे का विचार
कुछ authenticator apps simple approve/deny के बजाय login screen पर दिखाई संख्या phone में भरने को कहती हैं। Microsoft Entra documentation बताती है कि number matching MFA fatigue के विरुद्ध accidental approvals कम करने में मदद कर सकती है। फिर भी यह phish-resistant security की पूरी गारंटी नहीं। यदि user किसी नकली login page पर खुद credentials और सामने दिखी number साझा कर दे तो जोखिम बना रहता है। Number matching को stronger defence के रास्ते का एक intermediate उपाय मानें, अकेला अंतिम समाधान नहीं।
Passkeys और FIDO/WebAuthn की भूमिका
CISA phishing-resistant MFA के लिए FIDO/WebAuthn approaches की सिफारिश करती है। ऐसे authentication systems legitimate website origin से जुड़े cryptographic credentials इस्तेमाल करते हैं, जिससे spoofed website पर login complete करना कठिन हो सकता है। Organization में support उपलब्ध हो तो phishing-resistant method अपनाना साधारण push approval से मजबूत विकल्प है। लेकिन खोए device का recovery process, backup credential और employee onboarding भी तैयार होना चाहिए। किसी device में passkey available होने से सभी enterprise applications automatically compatible नहीं बन जाते।
School और office के लिए पहला incident response
यदि बिना login प्रयास के MFA prompts आने लगें, सभी requests deny करें। Official IT support channel से संपर्क करें, random caller या message के link से नहीं। सुरक्षित device पर account activity और active sessions की समीक्षा करें। Suspected password compromise हो तो approved account-management portal से password बदलें और session revocation की जरूरत देखें। Logs, prompt time और screenshot evidence सुरक्षित रखना जांच में मदद कर सकता है, पर screenshot में OTP या sensitive identifiers public group में साझा नहीं करें।
Password reset के बाद भी जाँच क्यों जरूरी
Attacker पहले से authenticated session या authorised OAuth app में बना रह सकता है, इसलिए केवल password बदलना हमेशा पूर्ण incident closure नहीं होता। IT team को unusual login locations, registered authenticators, recovery methods और third-party grants देखना चाहिए। Unsupported account recovery के डर से users को किसी random link से profile update करवाना अधिक जोखिमपूर्ण है। Standard incident procedure के तहत known-good session, trusted administration console और minimal permissions इस्तेमाल करें।
MFA prompt में location और device information
Authenticator कुछ login attempts के लिए approximate location, app name या device details दिखा सकता है। User को यह जानकारी जाँचनी चाहिए, मगर IP geolocation हमेशा सटीक नहीं होती। Travel, VPN और shared offices में legitimate login भी अलग शहर दिखा सकता है। Strong defence अपने initiate किए login attempt के साथ prompt की timing और displayed information को मिलाना है। ‘मैंने अभी इस service में login ही नहीं किया’ हो तो approval सुरक्षित नहीं माना जा सकता।
Helpdesk impersonation से बचाव
Fraudster अक्सर organization के manager या IT support का नाम लेकर employee से authenticator prompt accept करवाने की कोशिश कर सकता है। किसी भी administrator को employee से password, OTP, recovery code या unsolicited MFA approval नहीं माँगना चाहिए। Institution अपने official helpdesk email, internal extension और identity-check process कर्मचारियों को पहले से बताए। Urgent-sounding call आए तो उस call को काटकर ज्ञात directory के number पर वापस संपर्क करें। केवल WhatsApp profile photo देखकर support request पर विश्वास न करें।
Admin के लिए conditional access और rate controls
Enterprise identity systems में authentication strength policies, sign-in risk detection, protected admin accounts और failed-prompt monitoring उपलब्ध हो सकते हैं। Environment के अनुसार repeated failed MFA attempts पर investigation या temporary controls जरूरी हो सकते हैं। हर authentication product के features अलग हैं; Microsoft Entra की terminology अन्य identity provider पर लागू मानना गलत होगा। Admin को root cause खोजकर log retention तथा privacy rules के अनुसार alert policy तैयार करनी चाहिए।
Emergency accounts का सुरक्षित उपयोग
अगर organization के सभी administrators को strong MFA policy लगाई जाए और recovery व्यवस्था न हो, तो accidental lockout से संचालन रुक सकता है। इस कारण well-documented emergency access accounts, tightly controlled storage और periodic review महत्वपूर्ण हैं। इन्हें ordinary daily login के लिए इस्तेमाल नहीं करना चाहिए। Password तथा recovery material को shared spreadsheet में खुला न रखें। किसी staff change के बाद recovery ownership और revoked accesses जांचें।
Users के लिए 60-second rule
अचानक notification आए तो पहला सवाल है: क्या मैंने अभी login किया था? नहीं तो reject करें। दूसरा: क्या यह सही service और account से जुड़ा है? तीसरा: क्या किसी caller ने मुझे approval के लिए दबाव दिया? यदि हाँ, उस अनुरोध को scam मानकर independently verify करें। चौथा: क्या ऐसे prompts लगातार आ रहे हैं? हाँ तो security team को तुरंत बताएं। पाँचवाँ: क्या account में unusual sign-in हुआ? Activity log देखें। यह छोटा mental checklist दैनिक व्यवहार में सबसे उपयोगी हो सकता है।
SMS OTP बनाम app prompt बनाम security key
SMS OTP सामान्य password-only login से बेहतर हो सकता है, लेकिन SIM-swap और real-time phishing risks रहते हैं। App prompt convenience देता है लेकिन fatigue-style approval abuse के लिए susceptible हो सकता है। Number matching accidental accept घटा सकता है। FIDO security keys और platform passkeys origin binding के कारण phishing resistance बेहतर देने के लिए बनाए गए हैं। कौन-सा तरीका अपनाना है, यह employee devices, budget, application support और recovery policy के आधार पर तय करें।
क्या हर login prompt attack है
नहीं। User स्वयं दूसरे browser में sign-in कर सकता है या किसी old session की reauthentication मांग आ सकती है। कुछ systems multiple legitimate prompts भी generate कर सकती हैं। Security response में तथ्य जांचना महत्वपूर्ण है: event time, source application, device, IP indicator और user testimony। फिर भी unsolicited prompt को पहले deny करना सुरक्षित default है। किसी request को approve कर देने के बाद ‘शायद यह जरूरी login था’ मानकर incident ignore न करें।
Security awareness training कैसे बनाएं
15-minute training में कर्मचारी को genuine और unexpected sign-in prompts के sample screenshots दिखाएँ। केवल theory के बजाय mock scenario दें: ‘आपको रात दो बजे पांच notifications आते हैं, क्या करेंगे?’ उत्तर में deny, official reporting और credential review आए। Admin को अलग drill मिले जिसमें audit log, forced logout और support escalation शामिल हों। Training को shaming exercise न बनाएं; यदि कोई कर्मचारी mistake report करता है तो जल्दी response बेहतर होगा।
Audit checklist और success metrics
Track करें कितने staff ने phishing-resistant authentication अपनाया, कितने suspicious prompts report हुए, incident triage में कितना समय लगा और कितने accounts में least-privilege controls हैं। केवल login success count से program की security साबित नहीं होती। Incident review में कौन-सा factor काम आया, कहाँ approval गलत हुआ और policy कैसे बदली, यह लिखें। Repeated prompts को automatically ignored करने वाला culture सबसे बड़ी समस्या बन सकता है।
एक जरूरी अतिरिक्त सावधानी
यदि अचानक push notification बंद हो जाए और account भी खुलने लगे, तो यह सुरक्षा ठीक होने का प्रमाण नहीं है। Admin से authenticator registration तथा recovery methods चेक करवाएँ। Unauthorized device जुड़ना या active session बने रहना अलग समस्या हो सकती है।
Primary sources और सीमाएँ
CISA का Implementing Number Matching fact sheet push bombing का mechanism तथा mitigations समझाता है। CISA More Than a Password phishing-resistant MFA का संदर्भ देता है और Microsoft Entra documentation number matching का practical rationale बताती है। Procedures अलग providers पर बदल सकते हैं; यह guide किसी specific incident की forensic finding नहीं है।
इस विषय पर आगे क्या पढ़ें?
इस खबर से जुड़े विषयों को आसान भाषा में और गहराई से समझें।
