छोटा जवाब: किस स्थिति में कौन-सा तरीका
पासवर्ड शेयर करने की ज़्यादातर सलाह टूल पर बहस करती है। काम का सवाल इससे आसान है: इस क्रेडेंशियल को कितने समय तक चलना है, और किसे इसकी ज़रूरत है? इसका जवाब मिलते ही तरीका अपने आप तय हो जाता है।
| स्थिति | क्या इस्तेमाल करें | क्यों |
|---|---|---|
| ऐसा क्रेडेंशियल जिसे पूरी टीम महीनों तक इस्तेमाल करती है (साझा SaaS लॉगिन, सर्विस अकाउंट) | पासवर्ड मैनेजर में साझा वॉल्ट | इसे हमेशा अपडेट रहना है, एक ही जगह बदला जाना है, और जाने वाले लोगों से इसका एक्सेस हटाया जाना है। |
| एक बार का हैंडओवर (नए कर्मचारी का पहला लॉगिन, क्लाइंट का एडमिन पासवर्ड, किसी कॉन्ट्रैक्टर की डेटाबेस स्ट्रिंग) | वन-टाइम सीक्रेट लिंक | वैल्यू एक बार पढ़ी जाती है, फिर मिट जाती है। किसी के इनबॉक्स या चैट हिस्ट्री में कुछ नहीं बचता। |
| आपके वॉल्ट से बाहर के किसी व्यक्ति के लिए पासवर्ड (क्लाइंट, वेंडर, फ़्रीलांसर) | वन-टाइम सीक्रेट लिंक, पासफ़्रेज़ अलग से भेजें | बाहर के लोगों को कंपनी के वॉल्ट में नहीं बुलाया जा सकता; लिंक और किसी दूसरे चैनल से भेजे गए पासफ़्रेज़ के लिए उन्हें कोई अकाउंट नहीं चाहिए। |
| एक Wi-Fi पासवर्ड या दरवाज़े का कोड, आमने-सामने | बोलकर बता दें | कोई कॉपी नहीं बनती। यह तरीका बड़े पैमाने पर नहीं चलता और सुनने-लिखने में गलती हो जाती है, लेकिन एक वैल्यू के लिए ठीक है। |
| कुछ भी, कभी भी | ईमेल, Slack, Teams या SMS नहीं | चारों में खोजी जा सकने वाली एक कॉपी रहती है, जिस पर आपका कंट्रोल नहीं। देखें ये सबसे खराब चैनल क्यों हैं। |
टीमें पासवर्ड कैसे शेयर करती हैं: 5 तरीकों की तुलना
नीचे दिया हर तरीका कहीं न कहीं रोज़ इस्तेमाल होता है। टेबल इनकी तुलना उन बातों पर करती है जो पासवर्ड भेजे जाने के बाद मायने रखती हैं, क्योंकि गड़बड़ी तभी होती है।
| तरीका | बाद में कौन पढ़ सकता है | कितने समय तक रहता है | वापस लिया जा सकता है | ऑडिट ट्रेल | प्राप्तकर्ता को क्या करना पड़ता है | किसके लिए सबसे अच्छा |
|---|---|---|---|---|---|---|
| पासवर्ड मैनेजर का वॉल्ट | वॉल्ट के वे सदस्य जिनके पास एक्सेस है | जब तक आप उसे बदल या हटा न दें | हां (एक्सेस हटाकर) | हां (टीम प्लान में इवेंट लॉग) | अकाउंट और इनवाइट चाहिए | लंबे समय तक चलने वाले टीम क्रेडेंशियल |
| वन-टाइम सीक्रेट लिंक | सिर्फ़ इसे सबसे पहले खोलने वाला व्यक्ति | पहली बार खुलने या एक्सपायरी तक (LinkPilot: साइन इन वाले हर प्लान में 1 घंटा, 24 घंटे या 7 दिन, Pro में अपनी चुनी तारीख और समय; बिना अकाउंट वाले टूल में डिफ़ॉल्ट 7 दिन) | हां, खुलने से पहले तक | हां (बनाया गया / खोला गया / मिटा / वापस लिया गया) | कुछ नहीं: बस एक लिंक, और Pro में एक पासफ़्रेज़ | हैंडओवर, ऑनबोर्डिंग, बाहर के लोग |
| चैट (Slack, Teams, Signal) | चैनल के सदस्य, एडमिन, बाद में जुड़ने वाले लोग, एक्सपोर्ट | पेड Slack प्लान में डिफ़ॉल्ट रूप से वर्कस्पेस की पूरी उम्र तक | डिलीट करने से एक कॉपी हटती है; एक्सपोर्ट और स्क्रीनशॉट बचे रहते हैं | आंशिक (एडमिन ऑडिट, हर सीक्रेट का अलग नहीं) | कुछ नहीं | संवेदनशील कुछ भी नहीं: लिंक भेजें, वैल्यू कभी नहीं |
| ईमेल | दोनों मेलबॉक्स, दोनों प्रोवाइडर, बैकअप, सिंक होने वाला हर डिवाइस | अनिश्चित समय तक | नहीं | नहीं | कुछ नहीं | सीक्रेट का लिंक भेजने के लिए, सीक्रेट भेजने के लिए कभी नहीं |
| बोलकर, फ़ोन या SMS | बोलकर: कोई नहीं। SMS: दोनों फ़ोन और मोबाइल कंपनी | बोलकर: बिल्कुल नहीं। SMS: अनिश्चित समय तक | नहीं | नहीं | कम, लेकिन गलती की गुंजाइश रहती है | एक वैल्यू, आमने-सामने |
2026-10-02 को जांचा गया। Slack के डिफ़ॉल्ट रिटेंशन और SIM स्वैप के आंकड़ों के स्रोत इस गाइड के आखिर में दिए गए हैं; LinkPilot का व्यवहार सुरक्षा आर्किटेक्चर पेज से मेल खाता है।
पासवर्ड मैनेजर में साझा वॉल्ट
जो क्रेडेंशियल महीनों तक चलते हैं, उनके लिए पासवर्ड मैनेजर का साझा वॉल्ट सही डिफ़ॉल्ट है, जैसे 1Password, Bitwarden, Keeper, Psono और दूसरे। पासवर्ड एक ही जगह रहता है, उसे बदलने पर सबके लिए अपडेट हो जाता है, एक्सेस हर कलेक्शन के हिसाब से दिया जाता है, किसी के जाने पर बस उसकी सीट हटानी होती है, और टीम प्लान में इवेंट लॉग भी मिलते हैं। कमी यह है कि जिसे भी पासवर्ड चाहिए, उसे वॉल्ट के अंदर होना होगा, इसलिए किसी क्लाइंट, फ़्रीलांसर या ऐसे नए कर्मचारी को, जिसका अकाउंट अभी नहीं बना, वॉल्ट आइटम नहीं दिया जा सकता।
एक बार खुलने वाला एन्क्रिप्टेड लिंक
हैंडओवर के लिए वन-टाइम सीक्रेट लिंक सही टूल है। पासवर्ड पेस्ट करें, URL लें, और उसे उसी चैनल से भेज दें जो आप पहले से इस्तेमाल करते हैं। लिंक एक बार खुलता है: कॉन्टेंट दिखता है और फिर मिट जाता है, और थ्रेड में बचा URL कहीं नहीं ले जाता। छोटी समय-सीमा लगाएं, ताकि बिना खुला लिंक अपने आप खत्म हो जाए, और पासफ़्रेज़ दूसरे चैनल से भेजें, ताकि सिर्फ़ लिंक किसी के हाथ लगने पर वह बेकार रहे। आप बिना अकाउंट के अभी एक लिंक बना सकते हैं; टोकन के लिए यही तरीका LinkPilot बनाम Password Pusher और API keys सुरक्षित तरीके से कैसे शेयर करें में समझाया गया है।
चैट (Slack, Teams, Signal)
चैट अस्थायी लगती है, पर असल में उल्टा है। Slack के अपने दस्तावेज़ों में लिखा है कि पेड प्लान में “डिफ़ॉल्ट रूप से डेटा आपके वर्कस्पेस की पूरी उम्र तक रखा जाता है”, और वर्कस्पेस के मालिक इसे एक्सपोर्ट कर सकते हैं। Teams और Google Chat रिटेंशन और eDiscovery पॉलिसी के तहत आते हैं, जो इसीलिए बनी हैं कि मैसेज गायब न किए जा सकें। Signal बेहतर है, उसमें अपने आप गायब होने वाले मैसेज हैं और सर्वर पर कोई हिस्ट्री नहीं रहती, फिर भी यह दो फ़ोन पर रखी एक कॉपी है, साथ में स्क्रीनशॉट और बैकअप, जिन पर आपका कंट्रोल नहीं। ऊपर से हर चैट ऐप लिंक पोस्ट होते ही उसका प्रीव्यू बना लेता है, इसलिए वन-टाइम लिंक ऐसा बना होना चाहिए कि प्रीव्यू उसे मिटा न सके।
ईमेल
ईमेल से भेजा गया पासवर्ड सादे टेक्स्ट में भेजने वाले के मेल सर्वर पर, प्राप्तकर्ता के सर्वर पर, दोनों के बैकअप में और मेलबॉक्स सिंक करने वाले हर डिवाइस पर पड़ा रहता है। यह फ़ॉरवर्ड, आर्काइव और अकाउंट हैक होने के बाद भी बचा रहता है, और सालों बाद किसी मेलबॉक्स में सेंध लगने पर उससे कभी भी भेजा गया हर क्रेडेंशियल सामने आ जाता है। सीक्रेट का लिंक भेजने के लिए ईमेल ठीक है; सीक्रेट रखने के लिए ईमेल कभी ठीक जगह नहीं है।
बोलकर, फ़ोन और SMS
एक ही कमरे में पासवर्ड बोलकर बताने से कोई कॉपी नहीं बनती। इस पेज पर यही अकेला तरीका है जो कोई निशान नहीं छोड़ता, और अकेला ऐसा भी जो बड़े पैमाने पर नहीं चल सकता। SMS इसका खतरनाक रिश्तेदार है: मैसेज दोनों फ़ोन और मोबाइल कंपनी के रिकॉर्ड में बना रहता है, और फ़ोन नंबर चोरी हो जाते हैं। FBI के Internet Crime Complaint Center में अकेले 2021 में SIM स्वैपिंग की 1,611 शिकायतें दर्ज हुईं, जिनमें $68 मिलियन से ज़्यादा का नुकसान हुआ, जबकि 2018–2020 की पूरी अवधि में 320 शिकायतें आई थीं। SMS ऐसे छोटे पासफ़्रेज़ के लिए चल सकता है जो अलग से भेजे गए लिंक के बिना बेकार हो; पासवर्ड के लिए यह ठीक नहीं है।
ईमेल, Slack और SMS सबसे खराब चैनल क्यों हैं
ईमेल, चैट और SMS में एक बात साझा है, जो इन्हें इस काम के लायक नहीं छोड़ती: ये डेटा संभालकर रखने वाले सिस्टम हैं। हर एक इसीलिए बना है कि हर मैसेज की हूबहू कॉपी हमेशा के लिए ऐसी जगहों पर रखे जो आपको दिखती नहीं। इनमें से किसी में भी पेस्ट किया गया पासवर्ड मानो पहले से ही भविष्य के किसी हमलावर के लिए रख दिया गया है। खास तौर पर:
- अनिश्चित समय तक रिटेंशन। Slack पेड वर्कस्पेस का डेटा डिफ़ॉल्ट रूप से वर्कस्पेस की पूरी उम्र तक रखता है; मेल सर्वर मेल तब तक रखते हैं जब तक कोई उसे डिलीट न करे, और बैकअप उससे भी ज़्यादा समय तक।
- एडमिन और एक्सपोर्ट एक्सेस। वर्कस्पेस के मालिक चैट हिस्ट्री एक्सपोर्ट कर सकते हैं और मेल एडमिन किसी भी मेलबॉक्स को खोल सकते हैं, भेजने वाले की अनुमति के बिना।
- eDiscovery और लीगल होल्ड। होल्ड इसीलिए होते हैं कि मैसेज डिलीट न किए जा सकें। होल्ड में फंसा पासवर्ड हटाया नहीं जा सकता।
- फ़ॉरवर्ड और स्क्रीनशॉट। हर कॉपी की फिर से कॉपी बन सकती है; सादे टेक्स्ट वाला पासवर्ड जितनी जगहों पर मौजूद है, उनकी गिनती सिर्फ़ बढ़ती है।
- लिंक प्रीव्यू बनाने वाले बॉट और सिक्योरिटी स्कैनर। चैट ऐप और ईमेल गेटवे हर URL को पोस्ट होते ही खोलकर देखते हैं। लापरवाही से बना सीक्रेट लिंक इंसान के खोलने से पहले ही प्रीव्यू बॉट की वजह से मिट जाता है। देखें LinkPilot इसे कैसे रोकता है।
- SIM स्वैप और कंधे के ऊपर से झांकना। SMS में ये दोनों खतरे हैं, और मोबाइल कंपनी के पास भी एक कॉपी रहती है।
इसका हल बेहतर चैट टूल नहीं है; हल यह बदलना है कि चैनल से क्या जाता है: वैल्यू नहीं, एक पॉइंटर जो जल्द बेकार हो जाता है। ज़्यादा जानकारी URL से संवेदनशील जानकारी क्यों लीक होती है में।
पासवर्ड मैनेजर या वन-टाइम लिंक? कब कौन-सा
ये एक-दूसरे के पूरक हैं, प्रतिस्पर्धी नहीं। वॉल्ट स्टोरेज है; वन-टाइम लिंक डिलीवरी है। वॉल्ट क्रेडेंशियल को तब तक रखता है जब तक टीम को उसकी ज़रूरत है; लिंक उसे किसी एक व्यक्ति तक एक बार पहुंचाता है और पीछे कुछ नहीं छोड़ता।
अगर कोई क्रेडेंशियल आपके संगठन के अंदर बार-बार इस्तेमाल होगा, तो वॉल्ट आइटम शेयर करें। अगर उसे किसी एक व्यक्ति तक एक बार पहुंचना है, खासकर ऐसे व्यक्ति तक जो आपके वॉल्ट से बाहर है, तो वन-टाइम लिंक भेजें। इन दोनों में से किसी भी काम के लिए ईमेल या चैट गलत तरीका है। ज़्यादा जानकारी सीक्रेट लिंक बनाम पासवर्ड मैनेजर में।
वन-टाइम सीक्रेट लिंक असल में कैसे काम करता है
यहां “मिलिट्री-ग्रेड एन्क्रिप्शन” जैसे दावे नहीं हैं। यह असली मॉडल है, और हमारे सुरक्षा आर्किटेक्चर पेज से लाइन-दर-लाइन मेल खाता है। अगर कभी दोनों में फ़र्क दिखे, तो वही पेज सही माना जाएगा।
एन्क्रिप्शन आपके ब्राउज़र में होता है
29 सितंबर 2026 से, कुछ भी भेजे जाने से पहले कॉन्टेंट आपके ब्राउज़र में ही AES-GCM-256 से एन्क्रिप्ट होता है, वहीं बनी 256-बिट कुंजी से। हम तक सिर्फ़ एन्क्रिप्ट किया हुआ डेटा (सिफ़रटेक्स्ट) पहुंचता है, एक secret_links टेबल में, जो क्लिक एनालिटिक्स वाली टेबल से अलग है। अटैच की गई फ़ाइलें भी इसी तरह एन्क्रिप्ट होती हैं, सीक्रेट की अपनी कुंजी से बनी कुंजी से, इसलिए एक ही लिंक से दोनों खुलते हैं। इंजीनियरिंग की पूरी जानकारी: सीक्रेट शेयरिंग के लिए क्लाइंट-साइड एन्क्रिप्शन।
कुंजी लिंक में # के बाद वाले हिस्से में रहती है
शेयर लिंक shrd.link/s/<slug>#k=<key> जैसा दिखता है। # के बाद का पूरा हिस्सा डिक्रिप्शन कुंजी है, और ब्राउज़र लिंक का यह हिस्सा कभी किसी सर्वर को नहीं भेजते: न हमें, न उस CDN को जो सीक्रेट दिखाने वाला पेज देता है। हमें कुंजी कभी नहीं मिलती, इसलिए हम सीक्रेट पढ़ नहीं सकते, लिंक खो जाने पर उसे वापस नहीं ला सकते, और बाद में URL दोबारा नहीं बना सकते। साफ़ शब्दों में: जिसके पास पूरा लिंक है, उसके पास कुंजी है।
पासफ़्रेज़ सुरक्षा की दूसरी परत जोड़ता है
Pro में पासफ़्रेज़ को PBKDF2-SHA256 (2,10,000 इटरेशन) से मज़बूत किया जाता है और HKDF-SHA256 के ज़रिए लिंक की कुंजी के साथ जोड़ा जाता है, इसलिए न अकेला लिंक सीक्रेट को डिक्रिप्ट कर सकता है, न अकेला पासफ़्रेज़। अलग से, पासफ़्रेज़ का SHA-256 हैश भेजा जाता है, ताकि जो पासफ़्रेज़ नहीं जानता, उसे सर्वर सिफ़रटेक्स्ट लौटाने से मना कर सके; असली पासफ़्रेज़ हमारे डेटाबेस या लॉग में कभी नहीं लिखा जाता। हर सीक्रेट पर एक IP से प्रति मिनट 5 कोशिशों की सीमा है, और हर असफल कोशिश ऑडिट लॉग में दर्ज होती है। तुलना के लिए: NIST SP 800-63B के मुताबिक स्टोर किए गए याद रखे जाने वाले सीक्रेट को सॉल्ट करके, PBKDF2 जैसे key derivation function से कम से कम 10,000 इटरेशन के साथ हैश करना ज़रूरी है।
पढ़ते ही मिटना एक ही कदम में पूरा होता है
“पढ़ने के बाद मिटाएं” वाला लिंक प्राप्तकर्ता को कॉन्टेंट देखने का एक ही मौका देता है। खुलना एक ही डेटाबेस फ़ंक्शन के ज़रिए, row-level locking के साथ दर्ज होता है, इसलिए अगर दो लोग ठीक एक ही पल में लिंक खोलें, तो दोनों इसे नहीं पढ़ सकते। व्यू की सीमा पूरी होते ही स्टेटस “मिट चुका” हो जाता है और स्टोर किया गया कॉन्टेंट [REDACTED] से ओवरराइट कर दिया जाता है; बाद में आने वालों को HTTP 410 और साफ़ शब्दों में “पहले ही खोला जा चुका है” वाला पेज मिलता है। एक्सपायर और वापस लिए गए सीक्रेट भी इसी तरह मिटाए जाते हैं, और जानबूझकर इन्हें बहाल करने का कोई तरीका नहीं रखा गया है।
लिंक प्रीव्यू इसे मिटा नहीं सकते
सीक्रेट दिखाने वाले एंडपॉइंट पर GET सिर्फ़ मेटाडेटा लौटाता है: स्टेटस, और यह कि पासफ़्रेज़ चाहिए या नहीं। व्यू सिर्फ़ उस POST पर दर्ज होता है जो कोई इंसान “दिखाएं” पर क्लिक करके भेजता है, और सीक्रेट दिखाने वाले हर जवाब के साथ Cache-Control: no-store जाता है। चैट ऐप और ईमेल सिक्योरिटी गेटवे लिंक को सामान्य GET से खोलते हैं, इसलिए उनके प्रीव्यू को कुछ नहीं दिखता और कुछ भी नहीं मिटता। एक टेस्ट जो आप खुद चला सकते हैं: लिंक स्कैनर और वन-टाइम सीक्रेट।
हम अब भी क्या देख सकते हैं: तीन सीमाएं, साफ़-साफ़
- 29 सितंबर 2026 से पहले बनाए गए सीक्रेट एक्सपायर होने तक सादे टेक्स्ट में स्टोर थे। उन्हें चुपचाप दोबारा नहीं लिखा गया; वे पहले की तरह काम करते रहे और एक्सपायरी पर खत्म हो गए। जब तक वे एक्टिव थे, कोई ऑपरेटर उन्हें पढ़ सकता था। उस तारीख से पहले अपलोड किए गए अटैचमेंट सामान्य फ़ाइलों के रूप में ही स्टोर रहे।
- जिसके पास पूरा लिंक है, उसके पास कुंजी है। क्लाइंट-साइड एन्क्रिप्शन हमें, हमारे डेटाबेस और हमारे एज नेटवर्क को भरोसे के दायरे से बाहर कर देता है। लेकिन अगर प्राप्तकर्ता की तरफ़ लिंक फ़ॉरवर्ड हो गया, उसका स्क्रीनशॉट लिया गया या वह कहीं लॉग हो गया, तो यह उसे नहीं बचाता।
- फ़ाइल का नाम, साइज़ और प्रकार हमें दिखते रहते हैं। ये मेटाडेटा कॉलम हैं; कॉन्टेंट नहीं। सीक्रेट खोलने की हर कोशिश पर हम एक टाइमस्टैम्प, हैश किया हुआ IP (SHA-256, रोज़ बदलने वाले सॉल्ट के साथ, छोटा किया हुआ), मोटी-मोटी लोकेशन और यूज़र एजेंट भी रखते हैं। सीक्रेट, असली पासफ़्रेज़ या असली IP कभी नहीं, और लिंक खोलने वाले पर कोई कुकी नहीं।
ऑडिट ट्रेल और कंप्लायंस: ऑडिटर क्या मांगता है
जब क्रेडेंशियल एक हाथ से दूसरे हाथ जाते हैं, तो ऑडिटर तीन बातें पूछता है: किसने किसे क्या भेजा, क्या वह खोला गया, और क्या आप साबित कर सकते हैं कि अब वह कहीं नहीं है। वॉल्ट अंदर के लोगों के लिए पहले सवाल का जवाब देता है; ऑडिट टाइमलाइन वाला वन-टाइम लिंक हैंडओवर के लिए तीनों का जवाब देता है।
- हर सीक्रेट के इवेंट। हर सीक्रेट की अपनी टाइमलाइन होती है: created, viewed, failed_passphrase, burned, expired, revoked, हर इवेंट के साथ टाइमस्टैम्प और हैश किया हुआ IP। जिस व्यू की आपको उम्मीद नहीं थी, वह ऐसी सेंध है जिसका आपको वरना कभी पता नहीं चलता; क्रेडेंशियल बदल दें।
- डेटा न रखे जाने का सबूत। मिट चुके, एक्सपायर और वापस लिए गए सीक्रेट का कॉन्टेंट डेटाबेस में ओवरराइट किया जाता है, उस पर सिर्फ़ निशान नहीं लगाया जाता। “पासवर्ड अब कहीं नहीं है” वाली बात के पीछे यही ओवरराइट करने का तरीका है, कोई वादा नहीं।
- कम से कम डेटा। न असली IP, न लिंक खोलने वाले पर कुकी, न एनालिटिक्स या AI फ़ीचर में सीक्रेट का कॉन्टेंट; ये पाइपलाइन डेटा और कोड, दोनों स्तर पर अलग हैं। हमारा GDPR पेज यह व्यवस्था बताता है, और ट्रांसपेरेंसी पेज पर उन अनुरोधों की जानकारी है जो हमें मिलते हैं।
- दायरे के बारे में ईमानदारी। LinkPilot सीक्रेट लिंक के लिए SOC 2, HIPAA या PCI DSS सर्टिफ़िकेशन का दावा नहीं करता। इसे अपने कंप्लायंस प्रोग्राम के अंदर हैंडओवर का एक नियंत्रित चैनल मानें, यानी वह चीज़ जो ईमेल और चैट की जगह लेती है, सर्टिफ़ाइड सिस्टम ऑफ़ रिकॉर्ड नहीं।
प्लान से जुड़े तथ्य, ताकि क्लिक करने के बाद किसी को अचानक कोई सीमा न मिले: Free में “पढ़ने के बाद मिटाएं” और डिफ़ॉल्ट एक्सपायरी के साथ 5 एक्टिव सीक्रेट लिंक शामिल हैं; पासफ़्रेज़, कस्टम एक्सपायरी और पूरी ऑडिट टाइमलाइन Pro में हैं, $29 प्रति माह पर; लिंक वापस लेने के लिए अकाउंट चाहिए, क्योंकि बिना अकाउंट वाले टूल में डैशबोर्ड नहीं है। पूरी जानकारी कीमतें पेज पर।
अगर आप MSP चलाते हैं: ऑनबोर्डिंग, हैंडओवर और ऑफ़बोर्डिंग
मैनेज्ड सर्विस प्रोवाइडर तीन बार-बार आने वाली स्थितियों में क्रेडेंशियल शेयर करता है, और हर स्थिति अलग होती है। टेबल बताती है कि कहां कौन-सा तरीका सही है, उसी सोच के साथ जो इस पूरी गाइड में है: क्रेडेंशियल कितने समय तक चलता है और किसे उसकी ज़रूरत है।
| स्थिति | क्या इस्तेमाल करें | क्यों |
|---|---|---|
| क्लाइंट ऑनबोर्डिंग: पहला एडमिन पासवर्ड, राउटर लॉगिन, M365 ग्लोबल एडमिन अकाउंट | वन-टाइम सीक्रेट लिंक, पासफ़्रेज़ फ़ोन या SMS से | क्लाइंट के पास आपके वॉल्ट में सीट नहीं है। पहली बार पढ़ते ही मिट जाने वाला लिंक उसके इनबॉक्स में कुछ नहीं छोड़ता, और दूसरे चैनल पर भेजे गए पासफ़्रेज़ की वजह से अगर सिर्फ़ ईमेल किसी के हाथ लग जाए, तो वह बेकार है। |
| आपके अपने टेक्नीशियनों के बीच क्रेडेंशियल का हैंडओवर (टिकट किसी और को सौंपा गया, ऑन-कॉल रोटेशन) | स्थायी क्रेडेंशियल के लिए साझा वॉल्ट; बदली गई वैल्यू के लिए वन-टाइम लिंक | वॉल्ट मौजूदा वैल्यू को एक जगह रखता है। जब आप उसे बदलते हैं, तो नई वैल्यू एक बार भेजी जाती है और फिर मिट जाती है। |
| किसी क्लाइंट या टेक्नीशियन की ऑफ़बोर्डिंग | वॉल्ट में पासवर्ड बदलें, फिर एक्सेस हटाएं; बिना खुले लिंक डैशबोर्ड से वापस लें | जो लिंक कभी नहीं खुला, वह रास्ते में अटका हुआ क्रेडेंशियल है। उसे वापस लेना यह अंदाज़ा लगाने से तेज़ है कि वह पढ़ा गया या नहीं। |
| ऑडिट या क्लाइंट की सिक्योरिटी प्रश्नावली के लिए सबूत | हर सीक्रेट की टाइमलाइन (Pro) | बनाया गया, खोला गया, मिटा, एक्सपायर हुआ और वापस लिया गया, हर एक टाइमस्टैम्प के साथ: इससे चैट में खोजे बिना “किसके पास कब एक्सेस था” का जवाब मिल जाता है। |
दो काम की बातें। पहली, Slack के लिए LinkPilot ऐप उसी चैनल से वन-टाइम सीक्रेट बनाता है जिसमें आपके टेक्नीशियन पहले से काम करते हैं, इसलिए लिंक की आदत किसी वेबसाइट को याद रखने पर निर्भर नहीं रहती। दूसरी, मुफ़्त वन-टाइम सीक्रेट लिंक जनरेटर के लिए अकाउंट की ज़रूरत नहीं, जो तब काम आता है जब क्लाइंट के अपने स्टाफ़ को आपको पासवर्ड भेजना हो: उन्हें टूल का लिंक भेजें, चैट में पासवर्ड पेस्ट करने को न कहें।
पासवर्ड शेयर करने की पॉलिसी, जिसे आप कॉपी कर सकते हैं
छोटी टीमों में क्रेडेंशियल ज़्यादातर आदत की वजह से लीक होते हैं, हमलावरों की वजह से नहीं। छह नियम यह आदत खत्म करते हैं; इन्हें जैसे के तैसे अपनी हैंडबुक में कॉपी कर लें।
क्रेडेंशियल शेयर करने की पॉलिसी
- पासवर्ड, API keys, टोकन और कनेक्शन स्ट्रिंग कभी ईमेल, चैट या SMS में नहीं लिखे जाते। एक बार भी नहीं, “बस इस बार” भी नहीं।
- लंबे समय तक चलने वाले साझा क्रेडेंशियल टीम के वॉल्ट में रहते हैं। वॉल्ट आइटम शेयर करें, वैल्यू नहीं।
- एक बार के हैंडओवर के लिए वन-टाइम सीक्रेट लिंक इस्तेमाल होता है, जितनी छोटी चल सके उतनी छोटी एक्सपायरी के साथ और “पढ़ने के बाद मिटाएं” चालू रखकर।
- लिंक और पासफ़्रेज़ अलग-अलग चैनल से जाते हैं, लिंक ईमेल से और पासफ़्रेज़ फ़ोन या चैट के DM से, और पासफ़्रेज़ कभी दोबारा इस्तेमाल नहीं होता।
- ऑनबोर्डिंग में नए कर्मचारी की शुरुआती लॉगिन की जानकारी वन-टाइम लिंक से पहुंचती है और पहले लॉगिन पर बदल दी जाती है। रोल बदलने या ऑफ़बोर्डिंग पर उसी दिन वॉल्ट का एक्सेस बदला जाता है, और उस व्यक्ति के पास वॉल्ट के बाहर जो भी क्रेडेंशियल थे, वे बदल दिए जाते हैं।
- जो कुछ भी कभी चैट या ईमेल में पेस्ट हुआ, उसे अगली बार हाथ लगाते ही बदल दिया जाता है, और चैट का वह मैसेज डिलीट कर दिया जाता है। किसी सीक्रेट की टाइमलाइन में अनपेक्षित व्यू दिखते ही क्रेडेंशियल तुरंत बदला जाता है।
वेंडर और कॉन्ट्रैक्टर के साथ भी यही होता है, बस एक बात और: वॉल्ट में उनके क्रेडेंशियल की एक्सपायरी तारीख कॉन्ट्रैक्ट खत्म होने की तारीख रखी जाती है, और वह तारीख निकलते ही उन्हें बदल दिया जाता है।
पासवर्ड के लिए वन-टाइम लिंक अभी बनाएं
पासवर्ड पेस्ट करें, एक्सपायरी चुनें, लिंक भेजें। सामान्य सीक्रेट के लिए अकाउंट की ज़रूरत नहीं; अकाउंट से लिंक वापस लेने और टाइमलाइन की सुविधा मिलती है, और Pro में पासफ़्रेज़ और कस्टम एक्सपायरी।
स्रोत
- Slack: Customize message and file retention policies (“डिफ़ॉल्ट रूप से डेटा आपके वर्कस्पेस की पूरी उम्र तक रखा जाता है”)
- FBI IC3: Criminals Increasing SIM Swap Schemes to Steal Millions of Dollars from US Public (PSA, 8 फ़रवरी 2022)
- NIST SP 800-63B: Digital Identity Guidelines: Authentication and Lifecycle Management, सेक्शन §5.1.1.2 Memorized Secret Verifiers
- Bitwarden: About Send (टेक्स्ट और फ़ाइल वाले Send, एक्सपायरी, एक्सेस की गिनती)
- LinkPilot: सुरक्षा आर्किटेक्चर (ऊपर बताए मॉडल का आधिकारिक विवरण)