Copenhagen Book: वेब एप्लिकेशन authentication लागू करने की गाइडलाइन
(thecopenhagenbook.com)- वेब एप्लिकेशन में authentication implementation डिज़ाइन करते समय संदर्भ के लिए इस्तेमाल की जा सकने वाली बुनियादी गाइडबुक, जिसका लक्ष्य ऑनलाइन authentication सामग्री की कमियों को भरना है
- यह मुफ़्त और open source संसाधन है, और community-maintained तरीके से उपलब्ध कराया गया है
- कुछ सामग्री में राय शामिल हो सकती है या वह अधूरी हो सकती है, इसलिए इसे अकेले मानक के रूप में इस्तेमाल करने के बजाय सहायक सामग्री के रूप में उपयोग करना बेहतर है
- authentication security reference material OWASP Cheat Sheet Series के साथ इसका उपयोग करने की सलाह दी जाती है
- सुझाव या चिंताएँ एक नया issue खोलकर साझा की जा सकती हैं, ताकि दस्तावेज़ सुधार में भाग लिया जा सके
दस्तावेज़ का उद्देश्य और स्वरूप
- The Copenhagen Book वेब एप्लिकेशन में authentication(auth) लागू करते समय संदर्भ के लिए सामान्य गाइडलाइन प्रदान करता है
- इसका संचालन इस प्रकार है
- मुफ़्त में उपलब्ध है
- open source है
- community द्वारा maintain किया जाता है
- सामग्री कभी-कभी राय-आधारित हो सकती है या पूरी तरह पूर्ण नहीं हो सकती
साथ में देखने योग्य संसाधन और भागीदारी का तरीका
- authentication लागू करते समय OWASP Cheat Sheet Series के साथ इसे संदर्भ के रूप में देखने की सलाह दी जाती है
- यदि सुझाव या चिंताएँ हों, तो नया issue खोला जा सकता है
1 टिप्पणियां
Hacker News की टिप्पणियाँ
अगर मैं गलत नहीं समझ रहा, तो यह लेख TypeScript के लोकप्रिय authentication library Lucia के लेखक ने लिखा है
हाल ही में Lucia library ने घोषणा की कि अब वह authentication implementation के लिए ergonomic तरीका नहीं रह गई है, इसलिए library को बंद करके उसे लिखित guides की series से replace किया जाएगा
शुरुआती guide preview पढ़ने में अच्छा था और The Copenhagen Book के साथ भी अच्छी तरह फिट बैठता था
https://github.com/lucia-auth/lucia
https://github.com/lucia-auth/lucia/discussions/1707
https://lucia-next.pages.dev/
उन्होंने complexity के फटने के संकेत देखे, यह मान लिया कि library खुद उनके लिए भी अब उपयोगी नहीं रही, और common library bloat के standard रास्ते से विनम्रता से हट गए—यह दुर्लभ है
असल में 99% लोगों को सिर्फ login/logout चाहिए होता है, और जब यह library के रूप में मिलता है तो बेहद उपयोगी होता है
अगर आपको Web 8.0 passkeys को WASM elliptic-curve sockets के जरिए देना है, तो आप खुद बना सकते हैं या Auth0 इस्तेमाल कर सकते हैं, लेकिन CRUD cooking app बनाने वाले व्यक्ति के सामने OAuth spec और pitfalls की list रखकर उससे authentication खुद बनाने को कहना अजीब है
उस व्यक्ति को plumbing दोबारा invent करने के बजाय अपने असली idea पर focus करना चाहिए, और बहुत से लोग अंत में इसे गलत implement करेंगे, जिससे practically authentication न होने जैसी स्थिति बन सकती है
यह हिस्सा गलत है: “email address case-sensitive नहीं होते”
https://thecopenhagenbook.com/email-verification
email standard के अनुसार email address case-sensitive होते हैं
भेजने की प्रक्रिया में email को lowercase में बदलने से mail गलत व्यक्ति को जा सकता है, और authentication में यह खतरनाक है
कई जाने-माने email providers case-sensitive न होने का विकल्प चुनते हैं, लेकिन अगर कोई site general authentication संभालती है, तो उसे general case की सिफारिश करनी चाहिए
https://stackoverflow.com/questions/9807909/are-email-addres...
इसके अलावा, किसी character का opposite case क्या है यह हमेशा स्पष्ट नहीं होता, और समय के साथ बदल भी सकता है। उदाहरण के लिए German uppercase ß को 2008 में Unicode में जोड़ा गया था, इसलिए general programming में जहाँ संभव हो case distinction से बचना बेहतर है
standard एक बात कहता है, लेकिन implementations अलग तरह से behave करते हैं, और इस मामले में सिर्फ standard wording का पालन करने से real world में समस्याएँ पैदा होती हैं
इससे mail उसी casing वाले address पर भेजा जाता है जो पहले input किया गया था, और login case से independent रहता है
downside यह है कि केवल casing में अलग emails वाले दो users को अलग-अलग नहीं रखा जा सकता, लेकिन मुझे लगता है यह ठीक है
email case-sensitive नहीं था, लेकिन email से बना username case-sensitive था, इसलिए अगर uppercase letters वाले email से account बनाया, तो login के लिए वही casing type करनी पड़ती थी और case-insensitive email से login नहीं होता था
उसके बाद languages और cultural differences भी खत्म कर दें तो code की अरबों lines गायब हो जाएँगी, मुझे repositories के अभी से shrink होने की आवाज सुनाई दे रही है
उदाहरण के लिए, एक user entry में JohnDoe@example.com और दूसरी में johndoe@example.com है, जबकि साफ है कि यह वही व्यक्ति है
ऊपर से values अलग-अलग systems से आई थीं, इसलिए और भी सिरदर्द था
मेरे हिसाब से case-insensitive emails का risk matrix case-sensitive emails से कहीं बेहतर है। यानी सभी emails को lowercase में बदलना सही है, और The Copenhagen Book इस मामले में सही है
बहुत अच्छा। मुझे हमेशा यह शिकायत रही है कि security materials का 90% ऐसा लगता है जैसे security experts के अलावा कोई समझ ही न सके। खासकर cryptography material
लेकिन यहाँ की लगभग हर page साफ, concise, core points पर focused और तुरंत लागू करने लायक है, इसलिए पसंद आया
हालांकि elliptic curve वाला page बाकी cryptography material जितना ही समझने में कठिन था
इसके काम करने का तरीका ही mathematical है, इसलिए मुझे लगता है कि यह inherently opaque है
finite fields या elliptic curves, और practically integer groups को समझने के बाद मैं बहुत-सी cryptography समझ पाया, और आम तौर पर वह किसी न किसी रूप में discrete logarithm problem ही थी
इसी विषय पर वैकल्पिक दस्तावेज़ भी हों तो अच्छा होगा। जैसे OWASP Cheatsheet जैसा कुछ, लेकिन ज़्यादा व्यावहारिक दृष्टिकोण वाला दस्तावेज़
सम्मान है, लेकिन इस दस्तावेज़ को लेकर मैं थोड़ा संशय में हूँ
नाम काफ़ी भव्य है। दस्तावेज़ को ऐसे बुलाना जैसे इसे Copenhagen के विश्वविद्यालयी शोधकर्ताओं ने लिखा हो, एक बेहतरीन marketing trick है
यह सही है कि Lucia एक अपेक्षाकृत लोकप्रिय library है, लेकिन इसका मतलब यह नहीं कि यह best practices को promote करती है या लेखक को इस अहम क्षेत्र का authority माना जाना चाहिए
Lucia के design में कुछ हिस्से मुझे पसंद नहीं हैं। जब user token लगभग expire होने वाला हो, तो नया secure token बनाने के बजाय मौजूदा token की lifetime बढ़ाने का सुझाव दिया गया है
token असल में हमेशा के लिए ज़िंदा रहता है और उसका दुरुपयोग जारी रह सकता है, इसलिए यह बहुत असुरक्षित व्यवहार लगता है, और सीमित token lifetime वाली security best practice का उल्लंघन करता है
Lucia और “Copenhagen Book” दोनों यही तरीका recommend करते हैं: https://thecopenhagenbook.com/sessions#session-lifetime
यह आम तरीका है और आम तौर पर इसे rolling session कहा जाता है
token खुद शुरुआत से ही immutable होना चाहिए, इसलिए उसकी lifetime बदली नहीं जा सकनी चाहिए; इसलिए token renewal का मतलब मूल token बदलना नहीं, बल्कि नया token देना होता है
पहले case में attacker token चुराकर हमेशा के लिए इस्तेमाल करता रहता है। दूसरे case में भी attacker token चुराने के बाद expiry से ठीक पहले नया token ले ले, तो वह user बनकर जारी रख सकता है
user अगर बाहर निकाल दिया जाए तो शायद कुछ नोटिस करे, लेकिन संभावना कम है, और अच्छे user experience के लिए वैसे भी grace period चाहिए। नहीं तो parallel requests में legitimate user को भी समस्या होगी
दूसरा token, यानी refresh token, इस्तेमाल किया जा सकता है, लेकिन जोखिम बस उस token पर shift हो जाता है। अब चिंता यह करनी होगी कि refresh token चोरी होकर हमेशा के लिए abuse न हो
refresh token इस मायने में useful है कि हर request पर database hit करने की ज़रूरत नहीं होती। आम तौर पर short-lived session token को signed JWT की तरह database के बिना verify किया जा सकता है
लेकिन चोरी होने पर इसे invalidate नहीं किया जा सकता और expiry तक valid रहता है, इसलिए नुकसान घटाने के लिए expiry time छोटा रखना पड़ता है
इसके उलट refresh token database lookup करता है। दूसरा token खुद security नहीं जोड़ता; database lookup security जोड़ता है, क्योंकि database से delete करके उसे invalidate किया जा सकता है
Lucia कम-से-कम examples के आधार पर हमेशा database lookup करता है, इसलिए token को कभी भी invalidate किया जा सकता है
जोखिम कम करने के लिए user को active sessions देखने और समाप्त करने की सुविधा देनी चाहिए। संभव हो तो समय, location और device info भी दिखाना अच्छा है। जैसे: “कल सुबह 12 बजे Copenhagen के iPhone से login किया गया”
नए location या device से login होने पर user को notify भी किया जा सकता है
अंततः लंबे समय तक चलने वाले sessions को पूरी तरह सुरक्षित तरीके से implement करने का कोई तरीका नहीं है
मुझे लगता है यह अच्छी बात है, लेकिन मैं खुद को expert नहीं कह सकता
OAuth में दो चीज़ें हैं जिन्हें हर कोई miss करता है, और वे साफ़ दिखाई भी नहीं देतीं
उनमें से एक को किसी ने point out किया, यह देखकर अच्छा लगा। token इस्तेमाल करते समय transaction को distributed locking mechanism की तरह ज़रूर इस्तेमाल करना चाहिए
refresh token में इसका महत्व दोगुना, चौगुना हो जाता है। अगर वही token दो या अधिक बार इस्तेमाल हुआ, तो वह user logout हो जाएगा
system एक machine पर चल रहा हो या N machines पर, इससे फर्क नहीं पड़ता। अगर refresh token लगी दो या अधिक requests एक साथ चल रही हों—जो बहुत आम है—तो यह user को logout कर देगा और अक्सर 500 पर खत्म होगा
refresh token one-time-use होता है
developers और authentication frameworks दूसरी जो चीज़ miss करते हैं, वह “state” parameter है
आजकल authentication कुल मिलाकर जिस दिशा में बढ़ रही है, उसे देखकर लगता है कि यह obscurity के ज़रिए security नहीं, बल्कि obscurity के कारण instability के करीब जा रही है
जब application state भी इसमें उलझ जाए, तो application logic को authentication के हिसाब से adjust करना पड़ता है, और application को यह check करना पड़ता है कि किसी ने refresh token चुराया है या नहीं
सिर्फ transactions से समस्या हल नहीं होती। उदाहरण के लिए, अगर आप दो tabs जल्दी-जल्दी खोलें, तो मूल refresh token से server पर दो बार hit हो जाएगा
उस document में refresh token rotation को पसंद किया गया है, लेकिन cluster environment में आने वाली स्पष्ट कठिनाइयों को भी discuss किया गया है: https://datatracker.ietf.org/doc/html/rfc6819#section-5.2.2....
कई requests हमेशा एक साथ होती हैं। उदाहरण के लिए browser कई tabs के साथ start हो सकता है, या smartphone app start होते ही कई requests एक साथ भेज सकता है
काश ज़्यादा वेबसाइटें यह विकल्प देतीं कि “जब तक मैं लॉग आउट न करूं, session expire न हो; जोखिम समझता/समझती हूं”
आजकल “remember me” बटन का कोई असर नहीं होता
session expiry की वजह से दिन बार-बार टूटता रहता है। GitHub खास तौर पर नापसंद है: मैं उसे हफ्ते में करीब एक बार इस्तेमाल करता/करती हूं, इसलिए session हमेशा expire हो जाता है, और वह 2-factor authentication भी enforce करता है, जिससे हर बार फोन निकालकर नंबर डालना पड़ता है
user experience तो भयानक है ही, लेकिन बिना ठोस सबूत के भी मुझे लगता है कि बार-बार login करवाने से user थक जाते हैं और कम ध्यान देने लगते हैं
अगर आप किसी site पर हर हफ्ते कई बार login करते हैं, तो 60वें login के आसपास phishing site के बीच में आ घुसने की गुंजाइश बढ़ जाती है। इसके उलट, जिस account में लगभग कभी login करने की जरूरत नहीं पड़ती, वह अचानक password मांगे तो अजीब लगता है और सतर्कता बढ़ जाती है
आखिरकार कंपनियों को सीखना होगा कि हर व्यक्ति की risk tolerance और security posture अलग होती है, और विकल्प देने होंगे
ऊपर से GitHub की बार-बार session expiry और 2-factor authentication से इतना झुंझला गया/गई कि Gitea पर चला/चली गया/गई और expiry बंद कर दी। migrate करने की 90% वजह यही थी
क्योंकि access केवल मेरे network से ही संभव है, मुझे लगता है security उलटे बेहतर हुई है। अनलचीले security model की वजह से कोई company customer खो सकती है, यह पूरी तरह संभव है
मोटे तौर पर, अगर 30 दिनों के भीतर इस्तेमाल किया गया हो तो session को 30 दिन और जारी रखने वाला तरीका
https://thecopenhagenbook.com/sessions#session-lifetime
और भी बुरा यह है कि session एक हफ्ते से 1–2 मिनट ज्यादा चलता हुआ लगता है, इसलिए इस हफ्ते मैं पिछले हफ्ते का काम शुरू करते ही बाहर कर दिया जाता/जाती हूं
कुछ हफ्ते पहले recurring meeting से ठीक पहले notes लेने के लिए login किया था, और कई हफ्तों तक लगातार उसी meeting के बीच में login करने के लिए मजबूर किया गया
ऐसी बहुत-सी settings होती हैं जो उन “remember me” buttons को निष्क्रिय कर सकती हैं
निजी तौर पर मुझे GitHub समेत websites में login बने रहने में कोई समस्या नहीं हुई
हाल ही में SRP protocol के बारे में पता चला, और हैरानी है कि यह ज़्यादा इस्तेमाल या चर्चा में क्यों नहीं है
यह अपेक्षाकृत सरल protocol है, जिससे zero-knowledge proof किया जा सकता है और server व client के बीच session token भी एक साथ बनाया जा सकता है
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
यह material मुझे पसंद आया। बहुत-सी security advice कठिन और कभी-कभी बेतुकी लगती है। जैसे कोई वकील सलाह दे रहा हो कि कुछ भी मत करो
यह guide ताजगी देने वाली हद तक concise है, follow करना आसान है, समझने में अच्छी है, और इसमें सीधी-सादी advice है
विरोधी opinions या caveats हैं या नहीं, यह देखने के लिए comments पढ़ता/पढ़ती रहूंगा/रहूंगी, लेकिन लगता है इसे अपने authentication project के साथ compare करके review करूंगा/करूंगी
एक इच्छा है कि इसमें JWT section होता। अगर author की राय “इसे इस्तेमाल न करें” है, तो इतना कह देना भी ठीक होता
security teams को लेकर मेरी आम आलोचनाओं में से एक यह है कि वे लोगों को वे काम efficiently करने के tools या methods पहले से देने के बजाय, क्या नहीं करना चाहिए यह बताने में बहुत समय लगाते हैं
email को अपेक्षाकृत ज़्यादा सुरक्षित system माना जा सकता है, और हो सकता है वह तुरंत या हर जगह accessible न हो
यहां “auth” से मतलब authentication (authn) है या authorization (authz), यह जानना चाहूंगा/चाहूंगी
देखने में तो authentication लगता है, लेकिन स्पष्ट कर दिया जाए तो अच्छा होगा
थोड़ा संबंधित एक छोटी शिकायत: embedded browsers web को खराब कर रहे हैं
embedded browsers social OAuth का इस्तेमाल असंभव बना देते हैं। कुछ मामलों में सचमुच असंभव, और कुछ में व्यवहार में लगभग असंभव
Instagram में किसी link पर tap करें तो वह default रूप से Instagram browser में खुलता है, और अगर उस link पर “Sign in with Google” है, तो Google, Instagram जैसे “unsafe browser” को block कर देता है, इसलिए वह काम नहीं करता
“Sign in with Facebook” में भी समस्या आती है, जबकि Meta, Instagram और Facebook दोनों का मालिक है। Facebook embedded browser में भी ऐसी ही समस्या है
Slack जैसी जगह में link पर tap करने के बाद message का जवाब दें, फिर browser पर लौटकर उम्मीद करें कि वह page वहीं होगा, लेकिन Slack ने उसे अपने browser के अंदर निगल लिया हो और वह कहीं न मिले—यह लगभग हमेशा बेकार होता है
अच्छी बात है कि अभी check किया तो Slack में embedded browser बंद करने का तरीका है