प्रिय हब्रोज़िटेल! प्रिय विशेषज्ञों! मैं आपके मूल्यांकन के लिए वेबसाइटों पर उपयोगकर्ता पहचान की एक नई अवधारणा प्रस्तुत करता हूं, जो मुझे आशा है कि आपकी मदद से एक खुला इंटरनेट मानक बन जाएगा, जिससे यह इंटरनेट की दुनिया थोड़ी बेहतर हो जाएगी। यह पासवर्डलेस प्रमाणीकरण प्रोटोकॉल का एक ड्राफ्ट संस्करण है, जिसे एक मुफ्त लेख के रूप में डिज़ाइन किया गया है। और यदि यह अंतर्निहित विचार आपको प्रिय पाठक से एक सकारात्मक मूल्यांकन प्राप्त करता है, तो मैं इसे reddit.com और rfc-editor.org पर प्रकाशित करना जारी रखूंगा। और मुझे आशा है कि मैं इसके कार्यान्वयन में अग्रणी ब्राउज़रों के डेवलपर्स को रुचि दे पाऊंगा। इसलिए, मैं आपसे रचनात्मक आलोचना की अपेक्षा करता हूं।

ध्यान: पाठ का एक बहुत।


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

एक ओर, साइटों को क्रम में एक ग्राहक को पहचानने की आवश्यकता होती है, उदाहरण के लिए, उनकी सेटिंग्स, उत्पाद टोकरी, विज्ञापन, लेख आदि को "पुनर्स्थापित" करने के लिए। दूसरी ओर, आगंतुक अपने व्यक्तिगत डेटा को प्रकट किए बिना, यथासंभव अज्ञात रहना चाहते हैं और तृतीय-पक्ष साइटों को ट्रैक करने से रोकते हैं। और उत्तरार्द्ध खुद को एकत्रित आंकड़ों के बीच आदान-प्रदान करके ऐसा कर सकते हैं।

यह सुनिश्चित करने के लिए एक कार्य की तरह लगता है कि भेड़िये भरे हुए हैं, और भेड़ सुरक्षित हैं। क्या यह असली है?

मैं, कुछ हद तक, मुझे लगता है - वास्तव में।

सामग्री की तालिका

1 पासवर्ड रहित प्रमाणीकरण अवधारणा
1.1 लॉगिन और पासवर्ड के बजाय कुंजी और टोकन
1.2 टोकन संरचना
1.3 HTTP प्रोटोकॉल हेडर
1.4 ग्राहक साइटों की पहचान कैसे करते हैं?
1.4.2 मुझे कैसे पता चलेगा कि कोई साइट इस प्रोटोकॉल का समर्थन करती है?
1.5 ग्राहक साइटों को कैसे अधिकृत करते हैं?
1.6 विश्वसनीय ग्राहक पहचान कैसे लागू करें?
1.7 उपयोगकर्ता की आंखों के माध्यम से साइट पर प्राधिकरण
1.8 एक साइट कुंजी कैसे बदलती है?
1.9 क्रॉस-डोमेन प्राधिकरण कैसे लागू किया जाता है?
1.10 क्रॉस-डोमेन प्रमाणीकरण कैसे लागू करें?
1.11 खाता गतिशीलता

2 प्रोटोकॉल का तकनीकी विवरण
2.0 डोमेन कुंजी जनरेशन एल्गोरिथम
2.1 स्रोत टोकन की गणना के लिए एल्गोरिथ्म
2.2 हस्तांतरण के दौरान टोकन संरक्षण एल्गोरिथ्म
2.3 ब्राउज़र और सर्वर के बीच नमक विनिमय प्रक्रिया
2.4 प्रसंग क्षेत्र के गठन के लिए नियम
2.5 प्रेषक और प्राप्तकर्ता क्षेत्रों को परिभाषित करने के नियम
2.6 संदर्भ परिभाषा सारणी पर विवरण
2.7 प्रोटोकॉल परिदृश्य
2.8 सर्वर पर प्रसंस्करण प्रसंस्करण
2.9 क्रॉस-डोमेन प्रमाणीकरण

3 सुरक्षा सिफारिशें
3.1 अनधिकृत पहुँच से महत्वपूर्ण जानकारी का संरक्षण
3.2 डोमेन कुंजी के रूप में पासवर्ड के बारे में
3.3 चाबियाँ खोने / समझौता करने और उन्हें कम करने के जोखिम

4 प्राधिकरण योजना पर हमले
4.1 उपयोगकर्ता ट्रैकिंग
4.2 XSS हमला
4.3 सीएसआरएफ हमला
4.4 एसएसओ का उपयोग करके ट्रैकिंग
एसएसओ के लिए 4.5 प्रमुख समझौता
4.6 स्थानांतरण के दौरान टोकन समझौता
4.7 किसी वेबसाइट को हैक करना और टोकन से समझौता करना

निष्कर्ष

1 पासवर्ड रहित प्रमाणीकरण अवधारणा

1.1 लॉगिन और पासवर्ड के बजाय कुंजी और टोकन

प्रत्येक डोमेन के लिए, जिसमें बच्चे शामिल हैं, क्लाइंट ब्राउज़र यादृच्छिक रूप से एक अद्वितीय 256-बिट कुंजी बनाता है $$ । यह कुंजी कभी प्रसारित नहीं होती है। उपयोगकर्ता के सत्र के भीतर स्थिर रहता है। प्रत्येक नया सत्र एक नई कुंजी बनाता है।
कुंजी आधारित $$ ब्राउज़र एक विशेष एल्गोरिथ्म का उपयोग करके 256-बिट ^* टोकन उत्पन्न करता है $$ एक विशिष्ट डोमेन के साथ उपयोगकर्ता की पहचान करने के लिए। टोकन की पहचान $$ उपयोगकर्ता (इसके बाद केवल टोकन के रूप में संदर्भित) PHPSESSIONID और JSESSIONID जैसे सत्र कुकीज़ के प्रतिस्थापन के रूप में कार्य करता है।
कुंजी $$ उपयोगकर्ता द्वारा " निश्चित " किया जा सकता है। कुंजी को ठीक करने से उपयोगकर्ता विभिन्न ब्राउज़र सत्रों में असीमित समय के लिए साइट पर अधिकृत रहेगा और पहले से मौजूद प्राधिकरण को वापस कर देगा। यह "मुझे याद रखें" फ़ंक्शन का एक एनालॉग है ।
जब कमिट रद्द हो जाता है, तो ब्राउज़र इस कुंजी को "भूल जाएगा" और फिर से इस डोमेन के लिए प्रत्येक नए सत्र (वर्तमान से शुरू होने वाले) के लिए एक यादृच्छिक कुंजी उत्पन्न करना शुरू कर देगा, जो साइट से उपयोगकर्ता के "निकास" के अनुरूप है । आउटपुट तत्काल है, पृष्ठ पुनः लोड करने की आवश्यकता नहीं है।
उपयोगकर्ता डोमेन के लिए एक स्थायी कुंजी बना सकता है। स्थायी कुंजी, साथ ही निश्चित एक, उपयोगकर्ता को पिछले प्राधिकरण को वापस करने की अनुमति देगा। वास्तव में, यह कुंजी लॉगिन-पासवर्ड कनेक्शन के लिए एक प्रतिस्थापन बन जाती है।
उपयोगकर्ता को नियंत्रित करने का अवसर मिलता है जब डोमेन के लिए ब्राउज़र एक निरंतर कुंजी का उपयोग करेगा, और जब - यादृच्छिक। यह लॉगिन / लॉगआउट फ़ंक्शन का एक एनालॉग है । अवधारणा नीचे स्क्रीनशॉट में प्रस्तुत की गई है ।
लगातार डोमेन कुंजी बनाने के लिए तरीके विभिन्न उपकरणों के बीच उपयोगकर्ता खातों की गतिशीलता प्रदान करते हैं। प्रोटोकॉल निम्नलिखित को परिभाषित करता है:

• उपयोगकर्ता मास्टर कुंजी के आधार पर एक डोमेन कुंजी की पीढ़ी
• व्यक्तिगत रूप से एक जैविक यादृच्छिक संख्या सेंसर के आधार पर एक डोमेन कुंजी बनाने
• किसी अन्य डिवाइस से किसी कुंजी फ़ाइल से मौजूदा कुंजियों को आयात करना

1.2 टोकन संरचना

टोकन एक 256-बिट संरचना है, जिसे हेक्साडेसिमल स्ट्रिंग के रूप में दर्शाया गया है:

टोकन की पहचान वाला हिस्सा (उच्चतम 128 बिट्स) लॉगिन के समान है। बिट्स के इस क्रम से, सर्वर विशिष्ट रूप से उपयोगकर्ता की पहचान कर सकता है।
टोकन का प्रमाणीकरण हिस्सा (कम 128 बिट) पासवर्ड के समान है। बिट्स का यह क्रम सर्वर को टोकन को मान्य करने में मदद करता है।
टोकन सत्यापन नियम नीचे वर्णित हैं ।

1.3 HTTP प्रोटोकॉल हेडर

क्लाइंट द्वारा उपयोग किए जाने वाले हेडर:

CSI-टोकन : <टोकन> का उपयोग सर्वर को टोकन भेजने के लिए किया जाता है
सीएसआई-टोकन : < टोकन 1>; परिवर्तित- to <टोकनन 2> का उपयोग वर्तमान टोकन को बदलने के लिए किया जाता है:

• जब एक स्थायी कुंजी पर अधिकृत हो,
• स्थायी कुंजी पंजीकृत करते समय,
• स्थायी कुंजी बदलते समय।

CSI-टोकन : <टोकन> उपयोगकर्ता द्वारा वर्तमान यादृच्छिक कुंजी को ठीक करते समय स्थायी उपयोग किया जाता है।
सीएसआई-टोकन : <टोकन> लॉगआउट का उपयोग वर्तमान सत्र को समय से पहले समाप्त करने के लिए किया जाता है।

सर्वर द्वारा उपयोग किए जाने वाले हेडर:
CSI-Support: हाँ क्लाइंट को बताता है कि सर्वर CSI प्राधिकरण प्रोटोकॉल का समर्थन करता है।
CSI-टोकन-एक्शन: सफलता का उपयोग ब्राउज़र को नए उपयोगकर्ता टोकन (चेंज-टू की) की स्वीकृति के बारे में सूचित करने के लिए किया जाता है।
सीएसआई-टोकन-एक्शन: टोकन बदलने की प्रक्रिया को रद्द करता है (पिछले टोकन में रोलबैक)।
CSI-Token-Action: पंजीकरण ब्राउज़र को बताता है कि नया उपयोगकर्ता टोकन अभी भी पंजीकरण की प्रक्रिया में है।
CSI-टोकन-कार्रवाई: अमान्य सर्वर-साइड टोकन सत्यापन त्रुटि।

अंत में,
CSI-Salt को ब्राउजर और सर्वर द्वारा भेजा जाता है, जब टोकन (प्रमाणीकरण भाग) की रक्षा के लिए उपयोग किए जाने वाले "नमक" का आदान-प्रदान किया जाता है। अधिक जानकारी के लिए नीचे देखें ।

1.4 ग्राहक साइटों की पहचान कैसे करते हैं?

साइट आगंतुक की पहचान करने के लिए एक टोकन का उपयोग कर सकता है। इसी समय, टोकन पीढ़ी योजना और उनकी 256-बिट क्षमता प्रत्येक जोड़ी के लिए अद्वितीय टोकन की गारंटी देती है: उपयोगकर्ता-डोमेन। एक अन्य डोमेन दूसरे उपयोगकर्ता टोकन को देखेगा। भले ही लक्ष्य साइट (IFRAME, IMG, LINK, SCRIPT के माध्यम से) के संदर्भ में निष्पादित हो। इसके अलावा, एक विशेष टोकन पीढ़ी एल्गोरिथ्म उपयोगकर्ताओं को XSS, SRF हमलों से बचाता है और एक उपयोगकर्ता को उसकी जानकारी के बिना ट्रैक करना असंभव बनाता है। लेकिन एक ही समय में, एसएसओ तकनीक अपनी अनुमति और क्रॉस-डोमेन पहचान के साथ संभव है।
टोकन किसी भी डोमेन संसाधन (पृष्ठ, दस्तावेज़, छवि, स्क्रिप्ट, शैली, फ़ॉन्ट, फ़ाइल, AJAX अनुरोध, ...) के लिए हर अनुरोध के साथ सीएसआई-टोकन HTTP हेडर में प्रेषित किया जाता है :

प्रत्येक HTTP (एस) अनुरोध : पृष्ठ, चित्र, अजाक्स अनुरोध पर टोकन पुनर्गणना है ।
गणनाओं को अनुकूलित करने के लिए, ब्राउज़र द्वारा टोकन की कैशिंग की अनुमति है, लेकिन केवल सत्र की अवधि के लिए और केवल तभी जब अनुरोध को पूरा करने की शर्तें अपरिवर्तित रहें।
जैसा कि ऊपर उल्लेख किया गया है, टोकन PHPSESSIONID और JSESSIONID जैसे सत्र कुकीज़ के प्रतिस्थापन के रूप में काम कर सकता है। अंतर केवल इतना है कि यदि साइट पहले से ही अपने अलग-अलग अनुरोधों के बीच एक विशिष्ट उपयोगकर्ता को ट्रैक करने के लिए आगंतुक के लिए एक पहचानकर्ता उत्पन्न करती है (आखिरकार, एक ही समय में विभिन्न उपयोगकर्ताओं के हजारों अनुरोध साइट पर आते हैं), अब क्लाइंट स्वयं इस फ़ंक्शन को करता है।
इस तरह की पहचान आपको ऑनलाइन स्टोर में खरीदारी करने, उपयुक्त साइटों पर विज्ञापन देने, मंचों पर लिखने, सोशल नेटवर्क, विकिपीडिया या हबेरी लेखों पर लिखने की अनुमति देने के लिए पर्याप्त है।
हां, उपयोगकर्ता साइट के लिए गुमनाम रहता है। लेकिन यह साइट के लिए एक गुमनाम "परिचित" हो सकता है। और सर्वर अपने डेटा (व्यक्तिगत खरीद, वरीयताओं, कर्म, बन्स, पसंद और अन्य बोनस के साथ व्यक्तिगत खाते) के साथ इस तरह के उपयोगकर्ता के टोकन को अपनी तरफ से बचा सकता है। लेकिन केवल किसी भी व्यावसायिक प्रक्रिया के पूरा होने की स्थिति में रखने के लिए: खरीद, घोषणा प्रस्तुत करना, आदि। शर्तों को साइट द्वारा ही निर्धारित किया जाता है।
जैसा कि आप देख सकते हैं, प्रोटोकॉल उन साइटों के लिए जितना संभव हो उतना सरल है जो आपको कोई भी कार्रवाई करने का अवसर देने से पहले आपको पंजीकृत करने की आवश्यकता नहीं है। लेकिन जिन लोगों को इसकी जरूरत है, उन्हें थोड़ा और मुश्किल होगा। लेकिन इसके बारे में और नीचे।

1.4.2 , ?

http- CSI-Support: yes Response Headers :

, , . , :

, , www.youtube.com :

.

.

1.5 ?

, , – . , , – «».
, , , . .

: . . - .

« » . . « »:

, , . .
, , . .
, HTTP- CSI-Token-Action , . II .

1.6 ?

( , , ) , : , , . (, . , ).

1.7

, CSI, . , . :


, . :


, :


, -. . . , - / :


- «» :


. «» :

( ) HEAD, CSI-Token <>; Logout.

, , Logout. , ( ). , .
: , ajax-, .. – , .

: , , . «» . .

1.8 ?

, . II .
, , CSI-Token Changed-To :

. , , . . (Response Headers) : CSI-Token-Action: success , .
(, ) CSI-Token-Action: aborted.
, CSI-Token-Action, CSI-Token Changed-To.
« » .

1.9 - ?

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

साइट S पर एक नज़र डालें, जो Google के SSO का समर्थन करती है। मान लीजिए आपके पास एक Google खाता है। लॉग इन करने के लिए, आप "Google के साथ साइन इन करें" लिंक पर क्लिक करें, जिससे Google प्राधिकरण टैब खुल जाएगा। ब्राउज़र आपको बताएगा कि आपके पास Google की कुंजी है। और Google आपको बताएगा कि एस क्या अनुरोध करता है।
यदि आप सहमत हैं, तो मुख्य प्रबंधक में "लॉगिन" पर क्लिक करें। पेज पुनः लोड होगा। Google पहले से ही अपना मान्य टोकन प्राप्त करेगा, आपको पहचान और अधिकृत करेगा। और एक इंटर-सर्वर अनुरोध के साथ, यह साइट एस को आपके खाते की जानकारी के बारे में अनुरोध किए गए फ़ील्ड के अनुसार सूचित करेगा।
पुनः लोड किए गए पृष्ठ में एक "अगला" बटन होगा जो आपको लक्षित साइट पर लौटाता है।


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

भेद्यता: इस तरह के प्राधिकरण के बाद, साइटें S1, S2, S3, ... (जहां आपने Google के माध्यम से लॉग इन किया है) आपको पहचानने में सक्षम होंगे (Google द्वारा आपके द्वारा निर्दिष्ट पहचानकर्ता द्वारा) और, परिणामस्वरूप, अपनी गतिविधि को ट्रैक करें।

सुरक्षा विकल्प: यदि आप एक ही प्रदाता के एसएसओ के माध्यम से पंजीकृत हैं, तो साइटों पर एक साथ काम न करें। यदि संभव हो, प्राधिकरण पूरा होने के तुरंत बाद प्राधिकरण सर्वर से लॉग आउट करें (डोमेन के लिए "ऑटो-एग्जिट")।

1.10 क्रॉस-डोमेन प्रमाणीकरण कैसे लागू करें?

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

एक भौतिक एलियनेबल डिवाइस के माध्यम से स्थानांतरण

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

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

ऑनलाइन सेवा के माध्यम से सिंक करें

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

पेशेवरों: उच्च क्रेडेंशियल गतिशीलता; डिवाइस और ब्राउज़र स्वतंत्रता; आपको केवल एक ही पासवर्ड की आवश्यकता है (हालाँकि उन्होंने पासवर्ड नहीं छोड़ा है, यह पहले से बेहतर है)।
नुकसान: एक पराये मीडियम पर कीज़ स्टोर करने से कम सुरक्षित। वास्तव में, चाबियों की सुरक्षा चयन के लिए पासवर्ड की ताकत पर आधारित होती है।

आप निश्चित रूप से, अन्य कुंजी को एन्क्रिप्ट करने के लिए एक मास्टर कुंजी का उपयोग कर सकते हैं। वह जिसके साथ अन्य डोमेन कुंजी की गणना की जाती है। एक विकल्प के रूप में।

2 प्रोटोकॉल का तकनीकी विवरण

2.0 डोमेन कुंजी जनरेशन एल्गोरिथम

यह प्रोटोकॉल डोमेन कुंजियों को बनाने के लिए केवल 2 विधियों को परिभाषित करता है।

• एक यादृच्छिक संख्या जनरेटर (अधिमानतः जैविक) पर आधारित
• 256-बिट मास्टर कुंजी के आधार पर

बाद के मामले में, डोमेन कुंजी की गणना इस प्रकार की जाती है:

$$

जहाँ $$ - 256-बिट मास्टर कुंजी, डोमेन - डोमेन नाम जिसके लिए कुंजी बनाई गई है।
इसके बाद, HMAC एक हैश क्रिप्टोग्राफ़िक एल्गोरिथ्म है जो SHA-2 हैश फ़ंक्शन के 256-बिट कार्यान्वयन पर आधारित है।

किसी डोमेन कुंजी का समझौता या स्वैच्छिक प्रकटीकरण मूल मास्टर कुंजी से समझौता नहीं करता है।

मास्टर कुंजी उपयोगकर्ता क्रेडेंशियल्स की गतिशीलता के लिए एक तंत्र प्रदान करता है।

यदि "मास्टर" के आधार पर बनाई गई कुंजी को समझौता किया गया था, या ऐसी कुंजी से गणना की गई टोकन (साइट को हैक करने के परिणामस्वरूप) समझौता किया गया था, तो कुंजी को बदलना होगा। आप इसे एक यादृच्छिक 256-बिट कुंजी में बदल सकते हैं, या एक ही "विज़ार्ड" से उत्पन्न कर सकते हैं, एक संस्करण के अलावा:

$$

इसके बाद, प्रतीक $$ स्ट्रिंग संघनन संचालन (बाइट सरणियों) के लिए उपयोग किया जाएगा।

2.1 स्रोत टोकन की गणना के लिए एल्गोरिथ्म

उपयोगकर्ता के प्रमाणीकरण टोकन की गणना किसी भी डोमेन संसाधन के हर अनुरोध के साथ की जाती है। अनुरोध टोकन की गणना करने के लिए, निम्नलिखित डेटा लिया गया है:

• प्रेषक - अनुरोध के सर्जक का डोमेन नाम (यह एक पेज हो सकता है जिसमें आइफ्रेम या किसी और के डोमेन से एक स्क्रिप्ट हो जो भ्रूण करता है)
• प्राप्तकर्ता - प्राप्तकर्ता का डोमेन नाम (जहां अनुरोध भेजा जाता है),
• संदर्भ - अनुरोध निष्पादन संदर्भ,
• संरक्षण - 32 बाइट्स (256-बिट) का एक यादृच्छिक अनुक्रम, यदि प्रसंग खाली है; अन्यथा खाली है

अनुरोध शुरू करने वाले डोमेन के कुंजी K पर 256-बिट SHA-2 के साथ यह डेटा संक्षिप्त और हैश किया गया है :

$$

प्रसंग खाली नहीं होने पर एक वैध टोकन प्राप्त किया जाता है। लक्ष्य स्थल पर उचित पहचान के लिए, प्रेषक = प्राप्तकर्ता = प्रसंग को पूरा करना होगा।

संरक्षण के साथ, प्रसंग क्षेत्र, XSS और CSRF हमलों के साथ-साथ उपयोगकर्ता ट्रैकिंग से बचाने के लिए उपयोग किया जाता है।
प्रेषक / प्राप्तकर्ता / संदर्भ निर्धारित करने के नियमों पर अधिक विस्तृत विवरण नीचे दिया जाएगा।

2.2 हस्तांतरण के दौरान टोकन संरक्षण एल्गोरिथ्म

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

$$

जहाँ $$ - उच्च 128 बिट्स, $$ - मूल टोकन के निचले 128 बिट्स, $$ - स्ट्रिंग संघनन। इस मामले में, प्रारंभिक टोकन $$ सर्वर को पहले से ही पता होना चाहिए।

आदर्श रूप से, CSI-Salt को हर बार एक ब्राउज़र द्वारा सर्वर का अनुरोध करने पर बदलना चाहिए। हालांकि, कंप्यूटिंग संसाधनों के संदर्भ में यह एक महंगी आवश्यकता हो सकती है। इसके अलावा, यह सर्वर के समानांतर अनुरोध भेजने की क्षमता को "मार" सकता है।
इसलिए, गणनाओं को अनुकूलित करने के लिए, सीएसआई-नमक मूल्यों को अलग-अलग अनुरोधों में अपरिवर्तित रखने की अनुमति है, लेकिन एक सत्र से अधिक नहीं । यह एक समय सीमा (हर 5 मिनट में सीएसआई-नमक का परिवर्तन), या अनुरोधों की तीव्रता (प्रत्येक 100 अनुरोधों पर सीएसआई-साल्ट का परिवर्तन), या अनुरोधों की प्रत्येक श्रृंखला के बाद (ठहराव, क्लाइंट-सर्वर के समय) या एक मिश्रित संस्करण हो सकता है। यहां निर्णय ब्राउज़र डेवलपर्स के लिए छोड़ दिया गया है।
CSI-Salt को बहुत अधिक समय तक अपरिवर्तित रखने से संचरित टोकन की सुरक्षा कमजोर हो जाती है, जिससे हमलावर को टोकन अवरोधन करने की अनुमति मिलती है, जबकि वैध उपयोगकर्ता ने लॉगआउट पूरा कर लिया है और पीड़ित की ओर से अनधिकृत अनुरोध निष्पादित करता है।

2.3 ब्राउज़र और सर्वर के बीच नमक विनिमय प्रक्रिया

2.3.1 एक यादृच्छिक या अपंजीकृत ^[1] सर्वर कुंजी के आधार पर टोकन।

2.3.2 सर्वर द्वारा पंजीकृत कुंजी के आधार पर टोकन ^[1] ।

---

^{[१] एक टोकन को अपंजीकृत माना जाता है यदि वह: एक यादृच्छिक कुंजी के आधार पर बनाया गया हो; सीएसआई-टोकन-एक्शन: सफलता की प्रतिक्रिया के साथ चेंज-टू या स्थायी कुंजी भेजने के बाद सर्वर द्वारा स्वीकार नहीं किया गया था।
[२] सीएसआई-साल्ट परिवर्तन जिस समय के माध्यम से किया जाता है, वह स्वयं ब्राउज़र द्वारा निर्धारित किया जाता है। यह अनुरोधों की एक श्रृंखला के बाद, समय समाप्ति के बाद, कुछ निश्चित अनुरोधों के बाद हो सकता है। – CSI-Salt .
[3] 16- 128- . , : _salt || S _salt . – , . , , .}

2.4 Context

, ( ). . .

, . , . , , ajax- .

, . , <script>, , . , <script>, , , . <script> .

LINK, SCRIPT, IMG, IFAME , - , DOM – .

FORM, A, META , (submit, click, timeout) – .

, . , .

FORM , , INPUT, .

, , , , , , . .

. , , click ( ), submit ( ) onclick/onsubmit.

. – META http-equiv=«refresh» content=«0».

^{P. Context}


( SRC IMG), , , / , — , «».

^{R. Context /}

---

^{[1]
[2]
[3] Inherit , Empty
[4] Inherit , Empty (. )}


P1..PF, R1..RC .

Referrer Domain . , , , .

2.5 Sender Recipient

Sender – //, . , , . ajax. . .

Recipient – , .

, .

site.net. :

• site.net/css/common.css
• common.css fonts.google.com/fonts/Roboto.css
• Roboto.css fonts.google.com/fonts/Roboto.ttf
• , img.site.net/picture1.jpg
• , adriver.ru/frame
• adm.site.net/admin.js

( adriver.ru) :

• adriver.ru/style.css
• img.adriver.ru/img/01.png
• adriver.ru/libs.js
• api.adriver.ru/v1/ad.js

Sender / Recipient DOM

Sender / Recipient ajax-.

Sender / Recipient

2.6 Context

, ( ) , Context .

P1 – submit . / . . .

site.net google.com, Context (google.com). site.net ( , ).

( ) P1 , Context site.net, .. Context = Referrer.

CSRF -.

P5 – , / , ; submit , / ( FORM, INPUT). / .

P9 – , P5 , , ( ).

PD – . .

URL . .

, , , , , PG ( ). F5, , PG . Enter PD .

CSRF- .

Context, , F5 ( ). , - ( P1 ).

, site.net, , . , , … , , , site.net.

P2 – , , click/submit. , . .

, Context . , Context .

P6 – , P2 , / / .

PA – , P2 , / / .

PE – window.location.href window.open(…).

site.net , Context . Context = site.net.

ya.ru, maps.ya.ru, Context . Context , .

, – . CSRF-.

P3 – P2 , click/submit . Context ( ), ( ).

P7 – P6 , / / .

PB – PA , / / .

PF – PE , .

P4 – <META>. . . Context . PE .

P8 — <META>. / . , Context . PE . .

PC – P8 , . Context .

PG – . , , . , , . , Context .

CSRF- .

, Context .

, , ( ) HTTP- Header. , Context . – .

- -.

, - . SSO- – .

« » , - . :

1. ;
2. SSO- , ;
3. SSO-;
4. SSO-, Changed-To, - ;
5. - «», ;
6. P1 , -, (, ).
7. -, , .

, , , . UI- :

SSO-. .

, , Context .

R1 – ( ). Context Context .

, site.net adriver.ru, img.disk.com, HTTP- img.disk.com Context , site.net.

R4 – , R1 . / , DOM Parser . , site.net/index.html site.net/require.js ( <script src=…>) site.net/min.js, main.js. Context , site.net.

R7 – , R1 . / , Context 256- . evil.com/drop.js, site.net, site.net , .. .

RA – . , site.net/css/common.css, site.net/index.html, fonts.google.com/fonts/Roboto.css, fonts.google.com Referrer = site.net/css/common.css. Context Referrer. Roboto.css Roboto.ttf, fonts.google.com/fonts/Roboto.ttf Referrer = fonts.google.com/fonts/Roboto.css. Context Referrer, .

, , Roboto.css ( ) /, CSRF- :

@import "https://site.net/api/payment?victim_params" 

अधिकृत उपयोगकर्ता की ओर से site.net पर अनुरोध को पूरा करने की उम्मीद है। लेकिन हमलावर के लिए समस्या यह है कि site.net को उपयोगकर्ता से टोकन प्राप्त करने की उम्मीद है:

$$

फिर, ऐसे CSRF अनुरोध के साथ, ब्राउज़र एक टोकन बनाएगा:

$$

और साइट का एक अनुरोध एक गुमनाम साइट की ओर से आएगा, जिसके पास इन कार्यों को करने के लिए एक्सेस अधिकार नहीं हैं।

आरबी - सामग्री साइट की अपनी स्क्रिप्ट द्वारा अपलोड की जाती है। इस मामले में, अनुरोध टोकन की गणना करने के लिए प्रसंग का उपयोग किया जाता है, जो स्क्रिप्ट वाले पृष्ठ के बराबर है। Site.net/1.js स्क्रिप्ट के लिए site.net Context पेज से, यह पेज के खुद के Context के बराबर होगा।

ध्यान दें कि पृष्ठ का प्रसंग हमेशा पृष्ठ के डोमेन नाम के बराबर नहीं होता है और यह इस बात पर निर्भर करता है कि यह मूल रूप से कैसे खोला गया था।

मान लीजिए कि हमलावर की साइट bad.com हमलावर साइट site.net का पेज खोलती है, जहां site.net/util.js स्क्रिप्ट पेज URL के माध्यम से पारित मापदंडों के साथ एक अनुरोध निष्पादित करती है। हमलावर को उम्मीद है, URL के माध्यम से "अपने मापदंडों" को खिसकाकर, पीड़ित की ओर से महत्वपूर्ण कार्य करने के लिए अजाक्स अनुरोध को निष्पादित करने के लिए अपनी स्वयं की साइट.net/util.js स्क्रिप्ट को मजबूर करने के लिए।

मान लीजिए कि उपयोगकर्ता स्वयं एक सीधे लिंक के माध्यम से बुराई.कॉम पर चला गया। तब बुराई के लिए प्रसंग डॉट कॉम बुराई डॉट कॉम होगा। इसके अलावा बुराई.कॉम एक स्क्रिप्ट के साथ site.net/api/payment?victim_params स्क्रिप्ट खोलता है, एक हमले को अंजाम देने की उम्मीद करता है, लेकिन site.net के लिए प्रसंग क्षेत्र खाली होगा (PE / PF केस)। Site.net/utils.js स्क्रिप्ट, एक अजाक्स अनुरोध को निष्पादित करने के लिए, ब्राउज़र को site.net पृष्ठ से प्रसंग लेने के लिए मजबूर करेगी। और यह हमारे साथ खाली है। लेकिन तब site.net को इस टोकन के साथ एक अजाक्स अनुरोध प्राप्त होगा:

$$

जबकि अधिकृत उपयोगकर्ता के लिए यह अपेक्षित है:

$$

site.net एक अज्ञात टोकन देखेगा और उपयोगकर्ता की पहचान नहीं कर पाएगा। सुरक्षा ने काम किया।

वैसे, ऐसी योजना के कारण बोलना, पॉप-अप के माध्यम से क्रॉस-डोमेन प्राधिकरण का संचालन करना अवास्तविक होगा।

प्रोटोकॉल के तहत SSO को लागू करने के लिए, आपको प्राधिकरण सर्वर पृष्ठ के लिए एक नया टैब खोलना होगा। और उसी समय, उपयोगकर्ता को इस तरह के एक टैब को खोलना होगा। सबसे अच्छा विकल्प उपयोगकर्ता को लक्ष्य साइट से उपयुक्त लिंक खोलना है।

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

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

यदि साइट पृष्ठ किसी अन्य साइट से स्वचालित रूप से खोला गया था , तो आप वहां लॉग इन नहीं कर पाएंगे, भले ही आप स्वयं इस साइट को पुनः लोड करें। क्योंकि स्रोत एक शून्य मान से विरासत में मिलेगा। ब्राउज़र को इस तथ्य के बारे में उपयोगकर्ता को संकेत देना चाहिए (स्रोत = यादृच्छिक):

यह उन साइटों के खिलाफ सुरक्षा के लिए किया जाता है जो अन्य पॉप-अप विंडो को खोलने के लिए मजबूर करते हैं (स्वयं या उनकी बाहरी स्क्रिप्ट), और जो साइटें खुलती हैं, वे पूरी स्क्रीन पर एक ही साइट पर जाने वाले नकली "करीब" बटन को रीबूट या बनाएंगे। यानी यह आपको एक मान्य टोकन प्राप्त करने की उम्मीद में, आपको ट्रैक करने के प्रयास को रोकता है।

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

DOM में अटैक किए गए पेज में <script> टैग बनाने या संशोधित करने की चाल से कोई मदद नहीं मिलेगी। स्रोत फ़ील्ड रिक्त रहेगा।

लेकिन समान शर्तों के तहत, आंतरिक स्क्रिप्ट अपने पिछले मूल्य के बराबर स्रोत वाले प्रश्नों को जन्म देगी। और अगर मूल पृष्ठ में Source = Domain था, तो सबकुछ ठीक हो जाएगा। उपयोगकर्ता ऐसे अनुरोधों के लिए अधिकृत रहेगा।

लेकिन तृतीय-पक्ष संसाधनों (CDN) से डाउनलोड की गई स्क्रिप्ट के साथ, कुछ मामलों में समस्याएं उत्पन्न हो सकती हैं। और यह सही है, क्योंकि CDN कोड अखंडता की गारंटी नहीं है। यदि आप उपयोगकर्ता प्राधिकरण को नहीं खोना चाहते हैं, तो अपनी साइट पर स्क्रिप्ट रखें और उन्हें अपने डोमेन से डाउनलोड करें। यह कुछ ऐसा है जैसे https पेज पर http लिंक का उपयोग करने की मनाही है।

हम उस स्थिति का वर्णन करते हैं जो एक डेवलपर में गिर सकती है। उपयोगकर्ता क्रियाओं के परिणामस्वरूप, आपकी स्क्रिप्ट अधिकृत उपयोगकर्ता को साइट के पृष्ठों में से एक के लिए पुनर्निर्देशित करती है (उदाहरण के लिए, यह एक फ़ॉर्म द्वारा किया जाता है), जिससे उपयोगकर्ता अधिकृत रहता है। आपकी स्क्रिप्ट कॉल, उदाहरण के लिए, $ (फॉर्म) .submit () CDN से भरी हुई jQuery स्क्रिप्ट का उपयोग कर रही है। इस मामले में, ब्राउज़र देखता है कि कॉल स्टैक में, जो फ़ॉर्म के सबमिट ईवेंट को ट्रिगर करता है, बाहरी स्क्रिप्ट से एक फ़ंक्शन है। XSS / CSRF हमलों को रोकने के लिए, ब्राउज़र स्रोत फ़ील्ड को खाली करता है, और टोकन की पीढ़ी (केस P9 ) में यादृच्छिक बाइट्स जोड़ता है। नतीजतन, नए पृष्ठ पर उपयोगकर्ता अचानक अनधिकृत हो जाता है और ऑपरेशन पूरा नहीं कर सकता है। यह उन डेवलपर्स के लिए भ्रामक हो सकता है जो सीडीएन का उपयोग करने के लिए उपयोग किए जाते हैं।

2.7 प्रोटोकॉल परिदृश्य

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

.htaccess.

 <Directory "/var/www/html"> AuthType CSI AuthName "Restricted Content" AuthTokensFile /etc/apache2/.csi_keys Require valid-user </Directory> 

 cat /etc/apache2/.csi_keys 

 # # Client Self Identification tokens file # # CSI-Domain-Key UserName Role 84bc3da1b3e33a18e8d5e1bdd7a18d7a166d77ac1b46a1ec38aa35ab7e628ab5 MelnikovIN admin 6d7fce9fee471194aa8b5b6e47267f0348a24b70a0b376535542b996af517398 BoshirovAM user 

2.7.1

K , «» T , . , : , . , vsphere.local, :

 Sender = Recipient = Context = vsphere.local 

() , :

$$

, . 128 , CSI-Salt ^* . , :

$$

Hi – 128 , Lo – 128 .
, , - , .. .

---

^{* . « ».}

2.8

( )

Permanent

. , , . – . CSI-Token-Action: success CSI-Token-Action: abort.

Logout

, . «» , ( ), (« »).

, , . .

Change-To

T, – '.

: T' ( , ), ( 128 ).

---

^{* , .}

2.9 -

, - -, . , site.ru img.site.ru, download.site.ru, .

site.ru -, . , site.ru, , - . .

, .
site.ru :

$$

, site.ru site.ru :

• ( )

T ₁ (. R1 , R4 , RB ). site.ru.

site.ru, download.site.ru. ( R1 , R4 ):

$$

download.site.ru , ajax- site.ru ( RB , RC ).

domain :

$$

, , , A, B, C . - . , .

site.ru ajax- . ID != T ₁ , site.ru. ID T _x . ID . ID .

. , , .. site.ru .

3

3.1

, , .

.

:

• ( )
• «» ( )

, - ( « » ), . , PIN-; .

- . : ?

, -, «», -, , , : « - ».

^* ( ). , . 100% , . , , , .

, (.. ). ( ) , – . - .

: + ( API ). « ». .

, , . , , , . : .

( ). , , .

---

^{*, 32- 64- . .}

3.2

. , .

. . :

1. , «» , , . , -, .
   
   (), 8- , , .: ~!@#$%^&. : 26 + 26 + 10 + 8 = 70 . 8- 70 ⁸ .
   
   , , 10 ¹² . 70 ⁸ / 10 ¹² = ~576 . यानी ~10 . 5 . 10- 15 . 10 , 1-2 .
   
   , .
2. , .
3. , . यानी ( SHA-2).
4. , , , . .

3.3 /

-?

, . ?

, . -, -, . .

, , ? , ( « »)? « » ?

, , , . , . , (email, mobile). , (, ). , , 100% , – .

-, -.

? , . , , bitcoin. , - . . . «», .

-?
. - ( ) , , , - . , . javascript. . …

-?

. . शांत और शांत। . . .

. , , , – . : , . , -.

. ( ). . IP- , , .

4

4.1

, , . -, . -, - – .

, , :

1. ( , ).
2. ( ) .

2 : , . == .

, № 2. «» ( ), «», , . , .

№ 1. .

1 H ₁ , 2, 1 – H ₂ . , (H ₁ , H ₂ ) -.
3, 2, . 3 H ₃ , 2, 3 – H _2' != H ₂ (. ). , , .. .

, fingerprint . , .

: , . .

4.2 XSS

XSS – , victim.com . , CDN .

. - ( ), ( ), ( ).

– Source .

: XSS ( ), . «». -.

4.3 SRF

evil.com, . (GET/POST/HEAD/PUT/DELETE) , (, ). (, ). , Referer . , .

CSRF , . . , . GET- ( ) .

.

4.4 SSO

S ₁ S ₂ , , , SSO, . .. (- ), ( ), S ₁ .

A, . S ₂ , ( S ₁ ) H ₁ . . S ₁ , S ₂ .

S ₂ .

 <meta http-equiv="refresh" content="0"> 

.

S ₂ A «»:

, . S ₂ H ₂ (.. 2.4 P1: ).

S ₂ S ₁ , H ₁ H ₂ , H ₂ S ₁ . S ₁ S ₂ , .. .

, .. , .

: . S ₂ , . , S ₁ S ₂ . .

4.5 SSO

, SSO, . .

.

.

, SSO, SSO. , . यानी SSO – .

. .

- : Id- SSO . Id SSO . , .
(. « » ).

. , , SSO, - , .

. , – . - Id- . , , , .

: ( ). . . , . , , , .

. SSO ( , ). SSO ( !).

SSO (, ), .

4.6

, 100% . ( ), . .

SSL . HTTPS . , HTTP. .

, . .

– . , . . - , .

, , , Javascript . Cookie HttpOnly. ajax- .

: , , ( ). cookie .

: , , ; ( , ).

4.7

. . : , «». - – .

, -, .

, . . , .

, -: - .

, , , , . .

, , , -, :

$$

निष्कर्ष

, , : « ?»


! अफसोस। , «/».

1. , , popup

« cookie! , ! «», ».

popup . GDPR ( ).

. , cookie ! «». , . , +1 .

2. . SSO : OAuth, SAML, Kerberos .., , , ; - SSO, : « , ». . . , … , . = .



3. . . , . -, - . -. ?

4. , . . .

5. . XSS, CSRF. - . — .

6. . .

7. , . , , , , , , , . SQL-.

, , . «» , - . . , «-» .

– ,
.

---

पुनश्च
. Habr . , () . sergey201991[]. , . / . . -.

, , :

1. , , ;
2. ; , SSO
3. «», - : - ( )
4. -

. 1 — , : , 1000. .

. 2 — . . , . 80- , .

, !