- बार-बार authentication मांगने वाली policy बिना किसी वास्तविक security improvement के केवल user असुविधा बढ़ाती है
- MFA fatigue attacks जैसे आधुनिक security threats बढ़ने से दोहराया गया authentication उल्टा vulnerability बन सकता है
- operating system के screen lock feature और real-time access policy updates अधिक effective protection देते हैं
- sensitive काम शुरू करने से ठीक पहले ही अतिरिक्त authentication की ज़रूरत होती है; मनमाने छोटे login cycle अनावश्यक हैं
- modern access control approach users को बाधित किए बिना automatic और तेज़ी से policy लागू करती है
बार-बार authentication security को मज़बूत क्यों नहीं करता
repeated authentication से पैदा होने वाली समस्याएँ
- काम के दौरान session expire हो जाने पर बार-बार password और MFA (multi-factor authentication) दर्ज करने से productivity घटती है
- शुरू में केवल password दोबारा डालना पड़ता था, लेकिन MFA step जुड़ने के बाद समय की बर्बादी और user असंतोष दोनों बढ़ गए
- MFA request जितनी ज़्यादा बार आएगी, MFA fatigue attacks के सफल होने की संभावना भी उतनी बढ़ेगी
- पहले password को बार-बार बदलना या session expiry को बहुत छोटा रखना प्रभावी security उपाय माना जाता था, लेकिन latest guidelines इन्हें उल्टा नुकसानदेह मानती हैं
- security login interval पर नहीं, बल्कि access permissions की management और policy changes कितनी तेज़ी से लागू होते हैं, इस पर निर्भर करती है
authentication का मूल स्वभाव
- authentication आम तौर पर दो में से किसी एक चीज़ को साबित करता है
- device possession proof: Windows Hello PIN, YubiKey, smart card आदि के ज़रिए यह जाँचना कि device वास्तव में उसी व्यक्ति के पास है या नहीं
- identity proof: password, Face ID, Touch ID आदि के ज़रिए यह पहचानना कि user वही व्यक्ति है या नहीं
- Identity Provider (IdP) की मुख्य भूमिका identity verification पर केंद्रित होती है
- Face ID, Touch ID, Windows Hello जैसे सिस्टम device possession proof और identity proof को एक साथ संभालते हैं, इसलिए उनकी security अधिक मज़बूत होती है
- अक्सर admin इस चिंता में session expiry कम रखते हैं कि कहीं policy changes तुरंत लागू न हों
वास्तविक security threats और authentication की भूमिका
- अधिकांश attacker remote phishing के माध्यम से हमला करते हैं, और password चुराना बहुत आसान होता है
- remote attacks से बचाव के लिए secondary authentication (जैसे YubiKey) एक महत्वपूर्ण defence है
- device loss, theft जैसे physical attacks की स्थिति में सामान्यतः screen पहले से locked होती है
- उल्टा, जितनी बार login कराया जाएगा, attacker को credentials चोरी करने के अवसर उतने अधिक मिलेंगे, जिससे security पर नकारात्मक असर पड़ेगा
operating system और web services की भूमिका
- आधुनिक operating systems screen lock feature के माध्यम से user के सीट छोड़ते ही system को अपने-आप सुरक्षित कर देते हैं
- user असुविधा बढ़ाने वाले अतिरिक्त authentication की जगह automatic lock policy लागू करना बेहतर है
- shared computer न होने पर short web session expiry पुराने internet cafe दौर की बची हुई आदत भर है
- sensitive services (जैसे internet banking) को छोड़कर अनुचित session expiry policy अक्सर security और usability दोनों को घटा देती है
efficient और user-friendly security model
- sensitive काम से पहले immediate authentication (on-demand authentication) आदर्श है
- Tailscale SSH का check mode, Slack Accessbot आदि ज़रूरत पड़ने पर तुरंत user verification की सुविधा देते हैं
- operating system के screen lock enforcement को साथ में लागू करने पर security और convenience के बीच संतुलन बनाया जा सकता है
- continuous security posture checks (device posture check) और real-time access control user के व्यवहार से स्वतंत्र होकर अपने-आप चलते हैं
- उदाहरण:
- device offline हो, खो गया हो, या security check में fail हो जाए, तो तुरंत access revoke किया जा सकता है
- role change जैसी identity changes होने पर access policy अपने-आप update हो सकती है
- users से बार-बार authentication कराने की तुलना में real-time automation कहीं अधिक smart और safe है
निष्कर्ष
- बार-बार login security को प्रभावी रूप से नहीं बढ़ाता; उल्टा यह password reuse, phishing, MFA fatigue जैसी समस्याओं को बढ़ा सकता है
- शांत और automated security system ही सबसे अच्छा protection है
- Tailscale का लक्ष्य adaptive, intelligent और वास्तव में उपयोगी security प्रदान करना है
- system इस तरह बनाया गया है कि user को खुद login interval समायोजित न करना पड़े, और ज़रूरत के क्षण पर ही न्यूनतम authentication friction हो
- Tailscale की real-time security check capabilities को दूसरे apps तक भी बढ़ाया जा सकता है, जिससे legacy systems को भी सुरक्षित रखा जा सके
संदर्भ लिंक
4 टिप्पणियां
HN टिप्पणियों में भी यह बात आई थी, लेकिन तेज़ी से बदलते IT माहौल की तुलना में जड़ और पुराने standards पर आधारित security checks/नियम अक्सर बड़ी रुकावट बन जाते हैं। शायद यह ऐसी बात है जो फ्रंटलाइन पर काम करने वाले लोग पहले से ही अच्छी तरह जानते होंगे... हा हा
कोरिया की अनगिनत सेवाएं हर 30 दिनों में पासवर्ड रीसेट करने के लिए परेशान करने वाली सूचनाएं दिखाती हैं।
यह काफ़ी परेशान करने वाला है, क्योंकि इसे कई सालों तक व्यक्तिगत जानकारी की सुरक्षा संबंधी अनिवार्य ज़िम्मेदारी के नाम पर मजबूरन लागू कराया गया था... सिसक सिसक
Hacker News की राय
मुझे लगता है कि मजबूरी में समय-समय पर पासवर्ड बदलवाने या एक्सपायर कराने वाली नीतियां और बड़ी समस्या हैं। ऐसी नीतियां लोगों को अक्सर अकाउंट लॉकआउट की स्थिति में पहुंचा देती हैं (जैसे छुट्टी के दौरान पासवर्ड एक्सपायर हो जाए), और फिर उन्हें IT के पास जाकर, घंटों फोन पर IT से संपर्क करके reset करवाना पड़ता है, या किसी ऐसे सहकर्मी के जरिए संपर्क करना पड़ता है जिसका अकाउंट लॉक न हुआ हो।
कई (शायद ज्यादातर?) कंपनियां अब भी ऐसी नीतियां लागू करती हैं, जबकि NIST अब मनमाने password changes की सिफारिश नहीं करता।
NIST आधिकारिक दस्तावेज़
Microsoft भी कहता है कि password expiration ज्यादा नुकसानदायक है और इसकी सिफारिश नहीं करता।
Microsoft आधिकारिक दस्तावेज़
फिर भी IT या security पक्ष में शायद इन सिफारिशों को पर्याप्त "authoritative" नहीं माना जाता, और अब भी ऐसी policies को recommend करने वाले guides मौजूद हैं.
जब कभी किसी random site में login करते समय मजबूरन password reset करने का prompt आता है, तो मुझे लगता है कि यह time-based expiration की वजह से नहीं, बल्कि शायद account leak या compromise की वजह से होगा।
अगर site operator को पता हो कि कुछ specific accounts data breach list में शामिल हैं, तो अगली login पर forced password change मांगना मुझे उचित प्रतिक्रिया लगता है.
मैंने यह बात एक cyber security प्रबंधक से कही थी, तो उसने बताया कि PCI standards में periodic password changes की requirement है, इसलिए यह इस पर निर्भर करता है कि आप किस audit को ज्यादा महत्व देते हैं.
पहले यह policy इतनी परेशान करती थी कि मैं हर बार password के आखिर में a~z क्रम में एक-एक alphabet जोड़कर काम चला लेता था।
अच्छी बात यह है कि मेरी मौजूदा कंपनी में मैं 3 साल से वही password इस्तेमाल कर रहा हूं, और इससे मैं खुश हूं।
अगर मेरा password leak नहीं हुआ है, तो providers का मुझे नियमित रूप से उसे बदलने को कहना बेमानी लगता है।
यह अब भी किसी official standard की तरह लागू है, यह बात हैरान करती है.
आखिरकार मेरे सारे accounts 1234abcd@ pattern तक ही सिमट गए हैं.
Apple products की वजह से यह वाकई बहुत असुविधाजनक लगता है।
मैंने देखा है कि यह pattern लगभग सभी Apple products पर लागू होता है।
Mac पर TouchID set होने के बाद भी, App Store में Apple account से login करके app install करने की कोशिश करो तो बार-बार password डालने की window आ जाती है; जबकि TouchID से authenticate किया जा सकता है, फिर भी हर बार password मांगता है।
Free apps install करते समय भी यही होता है, और यह मुझे पूरी तरह अनावश्यक प्रक्रिया लगती है।
यह pattern मेरी spouse के iPhone पर भी कभी-कभी दिखता है।
फोन reset करके दोबारा setup करते समय खासकर Apple password बार-बार फिर से दर्ज करने को कहा जाता है।
जब TouchID से पर्याप्त security पहले से है, तब भी यह सब बार-बार होना बहुत खटकता है।
Apple services को non-Apple device से access करो तो असुविधा और भी ज्यादा गंभीर हो जाती है।
हर बार icloud.com पर login करते समय "इस device पर trust करें" दबाने के बाद भी अगले दिन फिर password + one-time code वाला 2FA process दोहराना पड़ता है।
अगर payment या app install के दौरान Face ID fail हो जाए, तो PIN का fallback देने के बजाय पूरा Apple account password ही दर्ज करवाया जाता है, और password manager app भी खोला नहीं जा सकता।
Checkout counter पर ऐसी स्थिति आ जाए तो यह सच में बेहद असहज अनुभव होता है।
यह जरूर जांचना चाहिए कि purchases approve करने के लिए TouchID enabled है या नहीं।
(Settings > Touch ID & Password में जाकर इसे set करना पड़ता है।)
अगर यह enabled न हो, तो बार-बार password मांगा जा सकता है।
अनुभव से कहूं तो restart के बाद शायद एक बार authenticate करना पड़ता है, उसके बाद ज्यादातर authentication TouchID से हो जाता है।
जब भी iPhone को Mac से connect करके sync करते हैं, तो "क्या आप इस device पर trust करते हैं?" वाला prompt Mac और iPhone दोनों पर आता है, और हर बार "Yes" चुनने के बाद भी अगली बार connect करने पर फिर वही सवाल पूछा जाता है।
जिन tasks में SUDO privileges चाहिए, उनमें re-authentication की मांग मुझे स्वाभाविक लगती है।
ऐसे में संबंधित tasks को एक साथ group कर दिया जाए, तो दोबारा authentication की संख्या कम की जा सकती है।
एक बहुत पुराना iPad मेरा बच्चा इस्तेमाल करता है, और वह iOS 10.3 पर है, इसलिए password manager app भी नहीं चलता, और browser भी 32-bit app है, इसलिए modern websites भी ठीक से नहीं खुलतीं।
इस वजह से App Store इस्तेमाल करते समय 50 characters से ज्यादा लंबा password हर बार हाथ से टाइप करना पड़ता है, जो बहुत झुंझलाहट भरा है।
मुझे लगता है कि ऐसे लेख जिन लोगों को पढ़ने चाहिए, वे security audits करने वाले auditors हैं।
जब तक उनके expected standards नहीं बदलते, तब तक बहुत-सी कंपनियां तथाकथित industry standards के नाम पर व्यवहार में मूर्खतापूर्ण policies का पालन करती रहेंगी।
खासकर कुछ sectors की छोटी कंपनियों को भी security audit में ऊंचे scores चाहिए होते हैं, इसलिए वे बड़ी संख्या में बेकार security procedures अपना लेती हैं।
हम जानते हैं कि कम से कम 6 ऐसे security controls हैं जो वास्तव में प्रभावी नहीं हैं, फिर भी वे मजबूरन लागू हैं; auditors अभी भी आसानी से बदलने को तैयार नहीं होते।
SOC2 audit के दौरान मैं लगातार NIST guidelines दिखाता आया हूं।
Link दिखाने पर ज्यादातर लोग अंततः NIST standards स्वीकार कर लेते हैं।
Apple और Microsoft दोनों corporate settings में ऐसी configurations support करते हैं जिनसे कंपनी की security team "remember my device" और "trust this device" options disable कर सकती है।
Auditors या CISO (Chief Information Security Officer) checklist-based audits ही करते हैं, इसलिए असली security बढ़ती है या नहीं, उससे उन्हें फर्क नहीं पड़ता; audit में approval मिलना ज्यादा महत्वपूर्ण हो जाता है।
ऐसी settings सिर्फ user inconvenience बढ़ाती हैं और व्यवहार में real-world security को और खराब कर देती हैं।
मुझे लगता है Microsoft ने PC gaming को भी इसी तरह खराब किया है।
Minecraft या Master Chief Collection जैसे games चलाने से पहले बेवजह re-authentication window आ जाएगी, यह सोचकर ही मैं टालता रहता हूं।
इसी झुंझलाहट की वजह से मैंने account पर 2FA भी बंद कर दिया।
यह सिर्फ गेम है, bank account verification नहीं; बस आराम से game खेलने दिया जाए।
सुना है हाल में QR code scan करके authenticate करने का feature आया है, लेकिन मुझे लगता है कि यह system बनाने वाला व्यक्ति वास्तविक user experience से कटा हुआ था।
लेख में एक ऐसी बात है जिसका लगभग जिक्र ही नहीं हुआ।
अगर UX (user experience) खराब हो, तो वह अपने आप में security vulnerability बन सकता है।
अगर system सामान्य रूप से ही अव्यावहारिक ढंग से व्यवहार करता है, तो जब सच में कोई समस्या आए, तब users बदलाव या असामान्य व्यवहार पहचान नहीं पाएंगे।
उदाहरण के लिए, अगर password input बहुत बार मांगा जाए, तो लोग आदतन उसे दर्ज करने लगते हैं, और ऐसे में phishing जैसे खतरे को आसानी से पहचान नहीं पाते।
इसके अलावा, अगर OS startup programs या background में चल रहे संदिग्ध code को ठीक से manage न करे, तो उसका दुरुपयोग करना और आसान हो जाता है।
यह भी समस्या है कि आम security experts "human psychology" को महत्वपूर्ण variable की तरह शायद ही कभी देखते हैं, और सब कुछ checklist या company-centric दृष्टिकोण से design किया जाता है।
ठीक product design से रोकी जा सकने वाली गलतियां भी बनी रहती हैं, लेकिन product/service providers regulation changes के मामले में consumers से कहीं ज्यादा सक्रिय रहते हैं, इसलिए सुधार आसानी से नहीं होते।
इसी वजह से मुझे सच में लगता है कि stronger regulation security performance में मदद कर सकती है, लेकिन कंपनियों के नजरिए से यह अजीब स्थिति है कि कोई भी अपनी product/service पर regulation का स्वागत नहीं करता।
बार-बार re-authentication मांगने वाले systems व्यवहार में security में सुधार नहीं करते (हालांकि बहुत लंबे expiration intervals कुछ हद तक अपवाद हो सकते हैं)।
अगर authentication system ठीक से बना हो, तो असली कुंजी यह है कि session expiration या explicit session management के जरिए permissions तुरंत वापस ली जा सकें।
व्यवहार में, जब session privileges revoke किए जाएं, तब उस session के पूरी तरह expire होकर सारी access खो देने तक की "latency" re-authentication interval से कहीं ज्यादा महत्वपूर्ण होती है।
और authentication architecture तथा configuration systems जितने ज्यादा होंगे, यह उतना ही जटिल बनता जाता है।
इसी वजह से refresh token की जरूरत होती है।
असल token नियमित रूप से expire होते रहते हैं, लेकिन client को नया token refresh करने का अलग अवसर दिया जाता है।
Token revocation इस तरह control की जाती है कि नया token बन ही न सके।
मैं भी लगभग ऐसा ही सोचता हूं।
हमारी कंपनी में two-step authentication model है।
दिन में एक-दो बार ADFS + MFA के जरिए keycloak में login करना पड़ता है, और ज्यादातर systems keycloak को OIDC provider की तरह इस्तेमाल करते हैं, जहां हर 10~15 मिनट में token refresh हो जाता है।
इसलिए आम तौर पर दिन में सिर्फ एक बार परेशान करने वाली authentication प्रक्रिया से गुजरना पड़ता है, और जरूरत पड़ने पर VPN से जुड़ी services की access को 15 मिनट के भीतर पूरी तरह बंद किया जा सकता है।
अच्छी बात यह है कि सामान्य उपयोग के दौरान यह बदलाव लगभग महसूस भी नहीं होता।
Re-authentication के लिए नहीं, सिर्फ मौजूदा token का periodic refresh होना काफी है।
Authentication (auth) expiration और authorization expiration times को अलग रखना बेहतर है।
अगर लोगों से बार-बार re-authentication करवाया जाए, तो वे उल्टे bypass ढूंढने लगते हैं।
वे password कागज पर लिखते हैं, Google Docs में सहेजते हैं, Yubikey पर Arduino + servo motor लगा देते हैं, SMS को email पर forward करते हैं, या TOTP codes Wechat पर भेजते हैं—हर तरह के "जुगाड़" पैदा हो जाते हैं।
आखिरकार दुविधा यही है कि जितनी ज्यादा असुविधाजनक authentication policies होंगी, उतना ही users कंप्यूटर को अपनी मर्जी से थोड़ा भी चलाने के लिए ज्यादा असुरक्षित bypass अपनाएंगे।
लेख में यह भाव है कि "अब ज्यादातर OS fingerprint/face authentication से unlock हो सकते हैं, इसलिए जगह छोड़ते समय screen lock न करने का कोई कारण नहीं है", लेकिन व्यवहार में workstations (desktop PCs) पर यह बात बहुत सीमित रूप से लागू होती है।
30 साल के field support अनुभव में मैंने fingerprint reader वाला desktop सिर्फ एक बार देखा है।
Cameras भी लगभग नहीं होते; इस समय जिन 5 locations के PCs मैं manage करता हूं, उनमें camera वाले computers 2% भी नहीं हैं।
Face recognition उपयोगकर्ताओं को असहज करने वाला अतिरिक्त कारण भी रखता है।
हम पहले से ही non-consensual, covert face recognition (CCTV, school/company/police आदि) के कारण अविश्वास से भरे हुए हैं, और इससे होने वाली असुविधा मुझे जायज लगती है।
भले ही hardware मेरा अपना हो, software companies व्यवहार में नैतिक सीमाओं की परवाह किए बिना मेरी autonomy में दखल देने वाले तरीके से design करती हैं।
इसीलिए मुझे लगता है कि security keys workstations के लिए ज्यादा उपयुक्त हैं।
Industry IT security policy में वही मानसिकता है जैसे "IBM खरीदने पर किसी की नौकरी नहीं जाती"—सब वही करते हैं जो बाकी सब कर रहे होते हैं।
System सच में टूटा हुआ है या नहीं, इससे कम फर्क पड़ता है; ज्यादा महत्वपूर्ण यह होता है कि "किताब में जैसा लिखा है" वैसा किया गया।
समस्या यह है कि यह किताब (standard) 30 साल पुरानी और बहुत खराब है।
इसलिए information security officer को यह समझाने में कि हर 3 महीने में password बदलने की जरूरत नहीं, बहुत भारी ऊर्जा लगती है।
एक customer company में हर system पर 30-minute session limit लगी हुई है।
मुझे Jira वैसे ही पसंद नहीं था, लेकिन अब किसी ticket को देखने भर के लिए भी बार-बार login करना पड़ता है, जो बेहद परेशान करने वाला है।
नतीजा यह कि काम करने के बजाय Hacker News ही पढ़ता रह जाता हूं।
अच्छी बात यह है कि आजकल ज्यादातर services कम से कम मेरे work contents को cache में रख लेती हैं।
SSO का नाम ही 'SINGLE sign on' है, लेकिन व्यवहार में यह अंतहीन repeated authentication मांगता रहता है।
समझ नहीं आता कि मुझे दिन भर में सैकड़ों बार SSO authenticate करने का संदेश क्यों देखना चाहिए।
मोबाइल फोन खोने/चोरी होने का जोखिम रखते हैं, इसलिए वहां कुछ हद तक यह समझ आता है; लेकिन desktop पर अब भी लोग shared computers (जैसे library) में logout किए बिना उठ जाते हैं, और बहुत-से users इस बात को समझते ही नहीं।
मेरी समझ में SSO का मतलब यह था कि कई systems में एक ही ID से login किया जाए, न कि login action सिर्फ एक बार ही किया जाए।