सर्वर लिखते समय लॉगिन और गेम लॉजिक को कैसे विभाजित करें?


9

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


4
YAGNI: आपको इसकी आवश्यकता नहीं है। समयपूर्व अनुकूलन लागू न करें। लॉगिन खेल के बहुत ही तुच्छ भाग की तरह लगता है, इसे विभाजित करने से कोई लाभ होने की संभावना नहीं है; एक बार आपके गेम के पास पर्याप्त उपयोगकर्ता होते हैं, जिनकी आप देखभाल करते हैं (आपको एक सर्वर पर अधिकतम उपयोगकर्ताओं का समर्थन करने में सक्षम होना चाहिए, दूसरों के साथ केवल अतिरेक के लिए), आप कुछ सॉफ़्टवेयर इंजीनियरों को काम पर रखने में सक्षम होंगे जो इस तरह की बात को समझते हैं।
मार्क

आपने एक भ्रामक उत्तर स्वीकार किया, आपको उस पर पुनर्विचार करना चाहिए, या आप अपने सिर में गलत धारणाओं और अपने कोड में सुरक्षा की झूठी भावना के साथ समाप्त करेंगे।
ओ ० '।

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

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

जवाबों:


3

हालांकि फिलिप का जवाब पूरी तरह से अच्छा है, थोड़ा अलग तरीका है कि लॉगिन सर्वर और गेम सर्वर के बीच एक कनेक्शन की आवश्यकता नहीं है, जो इस तरह के कनेक्शन के लिए मुश्किल है।

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

यह काम करता है क्योंकि:

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

या इसे और अधिक सरलता से रखने के लिए, हैश सुनिश्चित करता है कि प्रेषक के लिए अपना लॉगिन टोकन जाली होना लगभग असंभव है और इसलिए टोकन की जानकारी पर भरोसा किया जा सकता है।

किसी भी सुरक्षा उन्मुख हैशिंग के साथ, आपके द्वारा प्राप्त किए जा सकने वाले सर्वोत्तम हैश फ़ंक्शन का उपयोग करें - जिस समय लोगों को bcrypt, PBKDF2 और स्क्रीप्ट पसंद आते हैं - और यह सुनिश्चित करना कि आपकी गुप्त कुंजी बहुत लंबी है ताकि ब्रूट फ़ोर्स प्रजनन को अधिक व्यावहारिक बनाया जा सके।


बहुत चालाक, मैं इस समाधान को पसंद करता हूं। मेरा सवाल तो गुप्त कुंजी है। क्या यह एक पास वाक्यांश या कुछ और जैसा होना चाहिए? और क्या यह प्रत्येक उपयोगकर्ता के लिए अलग होना चाहिए?
user342580

यह काम नहीं करता है, या, यह वास्तव में @ फिलिप के जवाब का एक छिपा हुआ पुन: कार्यान्वयन है। यह विफल हो जाता है क्योंकि यह मानता है कि लॉगिन सर्वर और गेम सर्वर दोनों एक ही गुप्त कुंजी को जानते हैं। यदि वे दोनों कुंजी जानते हैं, तो उनमें से एक को इसे प्रदान करने के लिए दूसरे से संपर्क करना होगा। या आपको दोनों को भेजने के लिए किसी तीसरे पक्ष की आवश्यकता है। किसी भी तरह से, यह पहले की तरह सूंघने योग्य है।
ओ ० '।

@ भगवान, विचार यह है कि आप लॉगिन और गेम सर्वर दोनों के मालिक हैं और उन्हें गुप्त कुंजी प्रदान कर सकते हैं। यदि आप दोनों सर्वर के मालिक नहीं हैं, तो गेम सर्वर कैसे भी लॉगिन सर्वर के प्रमाणीकरण पर भरोसा कर सकता है?
काइलोटन

@ user342580: मैं किसी प्रकार के लंबे वाक्यांश का उपयोग करूंगा। यह प्रति उपयोगकर्ता अलग करने के लिए नहीं है, लेकिन अगर यह किया है, कि चोट नहीं होगा। जब तक क्रिप्टो हैश फ़ंक्शन पर्याप्त मजबूत होता है और आप इसे बदलते हैं समय-समय पर इसे कोई फर्क नहीं पड़ता।
काइलोटन

@ Kylotan वास्तव में, और आप उन्हें कुंजी कैसे प्रदान करते हैं? आप सर्वर से सर्वर की तुलना में, सर्वर से कनेक्शन को अधिक सुरक्षित क्यों मानते हैं?
ओ ० '।

8
  1. उपयोगकर्ता द्वारा खुद को लॉगिनसर्वर के लिए प्रमाणित करने के बाद, इसे एक टोकन (एक अद्वितीय, यादृच्छिक रूप से उत्पन्न होने वाला स्ट्रिंग जो अनुमान लगाया जाना है, बहुत लंबा है) दें।

  2. लॉगिन करने वाला एक गेमर को चुनता है। टोकन, उपयोगकर्ता नाम और उपयोगकर्ता के बारे में अन्य सभी प्रासंगिक डेटा को लॉगिन सेवर से उस सर्वर पर भेजें जो उसने उठाया था।

  3. क्लाइंट को गेमर के टोकन और टोकन भेजें। फिर उसे लॉगइनसेवर से डिस्कनेक्ट करें।

  4. क्लाइंट तब गेमरवर को उसके उपयोगकर्ता नाम और टोकन के साथ जोड़ता है।

  5. जब क्लाइंट का टोकन लॉगस्वरर द्वारा रिपोर्ट किए गए एक से मेल खाता है, तो आप इसे स्वीकार करते हैं।

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


तो bcrypt पर्याप्त का उपयोग करेगा? मैं bcrypt का उपयोग करके समय + उपयोगकर्ता नाम + पासवर्ड के हैश से एक टोकन बनाने के बारे में सोच रहा हूं।
1934 पर user342580

मुझे लगता है कि यह होगा। पासवर्ड जानते समय एक टोकन का अनुमान लगाया जा सकता है, लेकिन जब आप पासवर्ड जानते हैं, तो आप सामान्य तरीके से लॉग इन कर सकते हैं।
फिलिप

1
bcrypt तब तक काम करता है जब तक इनपुट उपयुक्त रूप से रैंडम और ungessuable हो। यदि आप सिर्फ समय का उपयोग करते हैं, तो हमलावर समय की भविष्यवाणी करने की कोशिश कर सकता है, फिर bcrypt चलाएं और टोकन प्राप्त करें। समय के साथ एक गुप्त नमक या सुरक्षित रैंडमाइज़र (जैसे / यूनिक्स / लिनक्स सिस्टम पर यादृच्छिक / देव) का उपयोग करना सुनिश्चित करें।
सीन मिडिलिचच

हो सकता है कि पासवर्ड किसी अन्य साइट पर समझौता किया गया हो, इसलिए मैं यह मानने से बचूंगा कि यह एक उपयुक्त रहस्य है।
सीन मिडिलिचच

1
@SeanMiddleditch जब पासवर्ड से छेड़छाड़ की जाती है, तो वैसे भी सभी सुरक्षा खो जाती है। एक हमलावर जिसने पासवर्ड प्राप्त किया है, उसके पास टोकन का अनुमान लगाने का कोई कारण नहीं है, क्योंकि वह सामान्य तरीके से लॉग इन करके एक प्राप्त कर सकता है।
फिलिप
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.