2011-01-12 11 views
6

टोकन आधारित प्रमाणीकरण की मेरी समझ यह है कि प्रमाणीकरण (शायद एसएसएल पर) पर, फ्लाई पर सस्ते उपयोगकर्ता सत्यापन के लिए उपयोगकर्ता को टोकन पास किया जाता है। इसका एक कार्यान्वयन सत्र प्रबंधन के लिए उपयोगकर्ता को पास की जाने वाली कुकी उत्पन्न करना होगा।टोकन आधारित प्रमाणीकरण की सुरक्षा

लेकिन, मेरी समझ यह है कि टोकन आधारित ऑथ (कम से कम कुकीज़ के माध्यम से) फायरशेप जैसे मध्य हमलों में मनुष्य के लिए अतिसंवेदनशील है।

क्या कार्यान्वयन के अन्य तरीके हैं जो इस प्रमुख सुरक्षा मुद्दे को स्कर्ट करते हैं, या क्या मुझे टीबीए की मौलिक गलतफहमी है?

उत्तर

10

आपकी समझ अच्छी है। मूल रूप से, एप्लिकेशन इसे कैसे देखता है, इस संदर्भ में, टोकन उपयोगकर्ता नाम और पासवर्ड भी हो सकता है। अगर किसी के पास टोकन है, तो वे स्वयं को आपके आवेदन में प्रमाणित कर सकते हैं। Http कुकी के मामले में मुख्य उद्देश्य उपयोगकर्ता नाम और पासवर्ड को लीक करने से बचने के लिए किसी को क्रॉस-साइट स्क्रिप्टिंग भेद्यता (एक्सएसएस) या अन्यथा के माध्यम से कुकी प्राप्त करनी चाहिए। हां, सही परिस्थितियों को देखते हुए वे "टोकन में" व्यक्ति के रूप में इस टोकन को "रीप्ले" कर सकते हैं, लेकिन उन्हें उपयोगकर्ता नाम/पासवर्ड जोड़ी से पता लगाने में सक्षम नहीं होना चाहिए, लेकिन फिर टोकन की गारंटी नहीं है एल्गोरिदम उत्पन्न करना कमजोर है, कहें, जैसे कि आपने BASE64 को उपयोगकर्ता नाम और पासवर्ड को एकसाथ एन्कोड करने का निर्णय लिया है और इसे मान के रूप में उपयोग किया है।

आमतौर पर आप सर्वर पक्ष पर टोकन -> उपयोगकर्ता मैपिंग सुरक्षित रखते हैं। तो आखिरकार आपकी सुरक्षा टोकन को सुरक्षित रखने और यह सुनिश्चित करने के लिए आधारित है कि उसका जीवनकाल नियंत्रित हो (उदाहरण के लिए यह समाप्त हो जाता है और/या केवल उसी आईपी से आपको दिया जाता है, जो कि क्रेडेंशियल्स के मूल प्रदाता द्वारा उपयोग किया जाता है - फिर से, सिर्फ एक उदाहरण)

आशा इस मदद करता है,

-Oisin

+0

बढ़िया है, धन्यवाद Oisin। – Devin