गोपनीय खाता संख्या को क्रेडेंशियल मानें: इसका ऑडिट करें

खाता संख्या का लेबल लगा फ़ील्ड अपने आप सार्वजनिक संदर्भ नहीं है, और लेबल परीक्षण नहीं है। परीक्षण यह है कि कब्ज़ा किस बात की अनुमति देता है: यदि संख्या जानने से कोई साइन इन होता है, कनेक्शन प्रोफ़ाइल डाउनलोड होता है या कोई डिवाइस अधिकृत होता है, तो वह संख्या जीवनचक्र वाला क्रेडेंशियल है। जब भी कोई सेवा संख्यात्मक पहचान देती है और उसे हानिरहित कहती है, मैं नीचे दिए पाँच जाँचें करता हूँ। हर जाँच एक छोटे रिकॉर्ड में एक पंक्ति बनाती है, और रिकॉर्ड ही परिणाम है, उत्पाद पर फ़ैसला नहीं।

सूची बनाएँ कि कब्ज़ा वास्तव में क्या देता है

संख्या जो भी कार्रवाई खोलती है, उसे अलग-अलग लिखें। पोर्टल में साइन इन, कॉन्फ़िगरेशन फ़ाइल लेना, नए डिवाइस को अधिकृत करना और स्वीकृत टनल साइन इन देना अलग-अलग अधिकार हैं, और सेवा एक को बाकी के बिना लागू कर सकती है। जो पोर्टल संख्या को एकमात्र फ़ील्ड के रूप में स्वीकार करता है, वह इस बारे में कुछ नहीं कहता कि टनल अपने साथी का प्रमाणीकरण कैसे करता है बाद में, या ट्रैफ़िक कुंजियाँ कैसे निकाली जाती हैं।

सामान्य मॉडल बताना आसान है: bearer क्रेडेंशियल वह है जिसे धारक अलग क्रिप्टोग्राफ़िक कुंजी का कब्ज़ा साबित किए बिना उपयोग कर सकता है, और यही वह भेद है जो RFC 6750 टोकन के लिए खींचता है। यह तुलना है, यह दावा नहीं कि संख्या-आधारित सेवा OAuth लागू करती है। यदि धारक को और कुछ नहीं चाहिए, तो संख्या को bearer रहस्य मानें और बाकी डिज़ाइन को उसी के अनुसार वर्गीकृत करें।

इसे संदर्भ की तरह नहीं, रहस्य की तरह बचाएँ

भंडारण वर्गीकरण से निकलता है। साइन इन कराने वाला मान पासवर्ड प्रबंधक में रहता है, स्क्रीनशॉट, क्लिपबोर्ड इतिहास, चैट संदेश या ब्राउज़र नोट में नहीं। स्क्रीनशॉट सामान्य लीक हैं: संख्या छोटी है और हानिरहित दिखती है, इसलिए वह ऐसे सहायता थ्रेड में पहुँचती है जो उस डिवाइस से अधिक जीता है जहाँ से आई।

फ़िशिंग दूसरा विफलता-प्रकार है और उसे परवाह नहीं कि संख्या कितनी बेतरतीब है। मूल्य चाहने वाला धोखेबाज़ आपसे उसे फ़ॉर्म में चिपकाने को कहेगा, और ऐसा क्रेडेंशियल जो कभी समाप्त नहीं होता और जिसका दूसरा कारक नहीं है, प्रयास के योग्य है। साइन इन का रास्ता बुकमार्क या ज्ञात पते से पाएँ, ऐसे संदेश के लिंक से नहीं जो संख्या भी माँगता है।

पुनर्प्राप्ति सामग्री को रहस्य का हिस्सा मानें। यदि ऑपरेटर ने पुनर्प्राप्ति कोड, PIN या ऐसा ईमेल पता भी जारी किया जो खाता रीसेट कर सकता है, तो वे अलग क्रेडेंशियल हैं जिन पर वही सुरक्षा शर्त लागू है। एक असुरक्षित रीसेट चैनल बाकी हर नियंत्रण को सजावट बना देता है।

अनुमान-प्रतिरोध और दर सीमा को साथ जाँचें

लंबाई केवल उत्पादन विधि के साथ अर्थ रखती है। पूर्वानुमेय क्रम से बनी लंबी संख्या क्रिप्टोग्राफ़िक जनरेटर से निकले छोटे मान से कमज़ोर है, और अंकों की प्रभावशाली संख्या अप्रत्याशितता सिद्ध नहीं करती। पूछें कि मान कैसे बनता है, इससे पहले कि सोचें कि इसका अनुमान लगाना कितना कठिन है।

केवल अनुमान-प्रतिरोध भी असीमित प्रयास दर के सामने नहीं टिकता। महत्वपूर्ण नियंत्रण वे हैं जो ऑपरेटर लागू करता है: असफल प्रयासों के काउंटर, लॉकआउट, प्रति-स्रोत थ्रॉटलिंग, और यह कि गलत संख्या अनुपस्थित से अलग पहचानी जाती है या नहीं। यदि सेवा इसे सहारा देती है, तो एक असफल प्रयास दिखाता है कि त्रुटि कैसी है और पुनः प्रयास काउंटर दिखता है या नहीं:

# one attempt, then read the response and any counter or delay
# do not script repeated guesses against a live account
curl -i -X POST https://portal.example.invalid/login -d "account=000000000000"

रिकॉर्ड करें कि प्रतिक्रिया क्या प्रकट करती है। अज्ञात खाते के लिए अलग त्रुटि गणना ऑरेकल है, भले ही संख्या का अनुमान लगाना असंभव हो, और यह निष्कर्ष रिकॉर्ड का हिस्सा है, चाहे आप इसे क्लाइंट पक्ष से ठीक कर सकें या नहीं।

रोटेशन और निरसन की योजना ज़रूरत से पहले बनाएँ

खोई या उजागर संख्या के लिए समर्थित प्रक्रिया खोजें और इसे तब लिखें जब सब कुछ चल रहा हो। क्या खाते का क्रेडेंशियल बदला जा सकता है? क्या बदलाव पहले से नामांकित डिवाइस, सक्रिय सत्र या डाउनलोड किया गया कॉन्फ़िगरेशन अमान्य करता है? प्रक्रिया कौन-सी पुनर्प्राप्ति सामग्री माँगती है? ईमेल पर निर्भरता के बिना सेवा उपयोगकर्ता को अधिक पुनर्प्राप्ति ज़िम्मेदारी दे सकती है, जो प्रक्रिया को अधिक महत्वपूर्ण बनाता है, कम नहीं।

खाता बदलने को क्रेडेंशियल निरसन से अलग रखें। यदि संख्या कुंजी, प्रमाणपत्र या प्रोफ़ाइल डाउनलोड करने का अधिकार देती है, तो संख्या बदलने पर वह डाउनलोड सामग्री वैध रह सकती है, और डाउनलोड सामग्री का निरसन अलग मालिक वाला अलग संचालन हो सकता है। यह न मानें कि एक बदला हुआ फ़ील्ड हर कनेक्शन समाप्त करता है; ऑपरेटर का वास्तविक मॉडल जाँचें और लिखें कि कहाँ सत्यापित किया।

निर्णय का दस्तावेज़ बनाएँ और बाद में दोबारा जाँचें

हर सेवा के लिए एक पृष्ठ का रिकॉर्ड रखें: संख्या कौन-से अधिकार देती है, कहाँ संग्रहीत है, कौन इसे रीसेट कर सकता है, उपयोग के क्या प्रमाण हैं, और खुलासे के बाद पहले घंटे में आप क्या करेंगे। यही रिकॉर्ड शब्दावली की बहस को ऐसे निर्णय में बदलता है जिसका कोई ऑडिट कर सके।

गोपनीयता के दावों का अपना दायरा होना चाहिए। बेतरतीब ढंग से बनी संख्या फिर भी स्थिर पहचानकर्ता हो सकती है जो खाता घटनाओं को समय में जोड़ती है; अप्रत्याशितता असंयोज्यता नहीं है, और कोई भी गुण रखे गए नेटवर्क मेटाडेटा के बारे में कुछ नहीं कहता। पूरे डिज़ाइन की तुलना करें, साइन इन स्क्रीन के फ़ील्ड गिनने के बजाय।

इसे दर्ज करने से पहले:

• संख्या के दिए सभी अधिकार सूचीबद्ध हैं, डाउनलोड और डिवाइस प्राधिकरण सहित।
• भंडारण और पुनर्प्राप्ति चैनल उसी मानक पर सुरक्षित हैं जिस पर स्वयं संख्या।
• उत्पादन विधि और दर सीमाएँ ज्ञात हैं, लंबाई से अनुमानित नहीं।
• बदलने की प्रक्रिया और निरसन की प्रक्रिया मौजूद हैं, और आप जानते हैं कौन किसे रद्द करता है।
• रिकॉर्ड बताता है कौन मान रीसेट कर सकता है और उपयोग के बाद कौन-से प्रमाण रहते हैं।