विशेष रूप से आपके प्रश्न के अंतिम बिट के बारे में: नहीं, असुरक्षित प्रमाणीकरण प्रणाली रखना कभी भी क्षम्य नहीं है। जब कंप्यूटर सुरक्षा की बात आती है, तो उपयोगकर्ता शायद ही प्रबुद्ध होते हैं। उपयोगकर्ता आपके छोटे गेम के लिए उसी पासवर्ड का उपयोग करते हैं जैसे वे अपने Google खाते, फेसबुक खाते, बैंक खाते, और इसी तरह करते हैं। यहां तक कि अगर आप यह दावा कर सकते हैं कि खराब इंटरनेट सुरक्षा आदतों का उपयोग करने के लिए यह उनकी गलती है, तो आप एक हैं जिन्हें ज़िम्मेदार ठहराया जाएगा यदि आपका गेम उपयोगकर्ताओं के लॉगिन क्रेडेंशियल्स को चोरी करने के लिए एक हमले के वेक्टर के रूप में उपयोग किया जाता है। एक डेवलपर के रूप में, जो बेहतर जानता है, एकमात्र नैतिक विकल्प हैं आपकी प्रमाणीकरण प्रक्रिया को ठीक से सुरक्षित करना या बिल्कुल भी नहीं।
कुछ अवांछित लेकिन संबंधित सलाह के रूप में, उपयोगकर्ताओं को आपके खेल के लिए वैसे भी साइन अप करने की आवश्यकता नहीं है। यदि वे आपके खेल को बुरी तरह से खेलना चाहते हैं तो वे ऐसा कर सकते हैं, लेकिन साइन अप करने के लिए अभी तक एक और भयावह लॉगिन करने के लिए कई संभावित खिलाड़ियों को दूर करना है। उपयोगकर्ता हर एक साइट, सेवा और गेम के लिए एक नया खाता बनाने के लिए बीमार हैं, खासकर अगर उन्हें किसी भी तरह के ईमेल सत्यापन या इस तरह की आवश्यकता होती है। यदि आप कर सकते हैं, तो या तो लॉगिन करने से बचें, या किसी मौजूदा तृतीय-पक्ष प्रमाणीकरण सेवा का उपयोग करें जिसका उपयोगकर्ताओं के पास पहले से ही खाता है। आपके पास इस तरह से अधिक खिलाड़ी होंगे। अगर आप किसी भी तरह के इन-ऐप खरीदारी की योजना बनाते हैं तो यह तीन गुना हो जाता है।
वेब गेम्स
एक लोकप्रिय विकल्प - विशेष रूप से वेब गेम के लिए, हालांकि यह पारंपरिक खेलों के लिए भी काम करता है - वेब आधारित तृतीय-पक्ष प्रमाणीकरण सेवा का उपयोग करना है। प्रमाणीकरण के लिए फेसबुक और Google दोनों के पास अच्छी तरह से प्रलेखित एपीआई (दोनों मानकीकृत एपीआई पर आधारित है, iirc) है। उन्हें ब्राउज़र विंडो खोलने और उपयोगकर्ता को अपनी सेवाओं के लिए निर्देशित करने की क्षमता की आवश्यकता होती है, लेकिन अधिकांश गैर-कंसोल प्लेटफार्मों और वेब गेमों के लिए निश्चित रूप से यह बहुत आसान है।
वे सेवाएं वायर पर लॉगिन ट्रैफ़िक को एन्क्रिप्ट करने, लॉगिन क्रेडेंशियल्स को सुरक्षित रखने और उपयोगकर्ता लॉगिन को मान्य करने के सभी गंदे विवरणों का ध्यान रखती हैं। आपके गेम सर्वर को तब केवल उस प्रोटोकॉल के भाग को लागू करने की आवश्यकता होती है जो उपयोगकर्ता से कुकी प्राप्त करता है और प्रमाणीकरण सेवा से पूछता है कि क्या कुकी मान्य है या नहीं, जो कि ज्यादातर मामलों में एक साधारण HTTP के साथ की जा सकती है।
मैं दावा नहीं करूंगा कि अधिकांश पारंपरिक मल्टीप्लेयर गेम ऐसा करते हैं, क्योंकि वे नहीं करते हैं, लेकिन मैं यह दावा करूंगा कि अधिकांश ऑनलाइन कैज़ुअल वेब गेम ऐसा करते हैं।
पारंपरिक (नॉन-वेब) गेम्स के लिए, ब्राउज़र (एव्सोमियम, क्रोमियम एंबेडेड फ्रेमवर्क, या स्ट्रेट अप वेबकिट लोकप्रिय विकल्प) को एम्बेड करके या बाहरी ब्राउज़र पर कॉल करके इस लॉगिन प्रक्रिया की सुविधा संभव है। हालांकि बाहर से कुकी प्राप्त करें, और वास्तव में पूर्वोक्त पुस्तकालयों में से एक को एम्बेड करने की तुलना में कोई आसान नहीं है)।
इस दृष्टिकोण का एक विशिष्ट उदाहरण कोई भी फेसबुक गेम है।
HTTPS का उपयोग कर पारंपरिक खेल
लॉगिन के लिए सरल HTTPS सेवा का होना सामान्य है। कई गेम कस्टम प्रोटोकॉल का उपयोग करते हैं, लेकिन इनमें से अधिकांश अपूर्ण हैं (उनके पास सुरक्षित लॉगिन है, लेकिन खाता बनाने / अपडेट करने का कोई सुरक्षित तरीका नहीं है, इसलिए उन्हें HTTPS सेवा की आवश्यकता है) या बस भयानक रूप से असुरक्षित हैं।
आपको एक कस्टम एसएसएल सर्टिफिकेट प्राप्त करने की भी आवश्यकता नहीं है। ऑनलाइन ऐप होस्टिंग प्रदाता हैं जो आपको एक उपडोमेन देते हैं और वाइल्डकार्ड एसएसएल सर्टिफिकेट का उपयोग करते हैं। आप mygame.someservice.com पर अपनी प्रमाणीकरण सेवा डाल सकते हैं, जो * .someservice.com वाइल्डकार्ड सर्टिफिकेट द्वारा कवर किया जाता है कि कुछ सेवा बनाए रखता है, और आप जाने के लिए अच्छे हैं।
यहां विचार यह है कि उपयोगकर्ता आपकी सेवा में लॉग इन करता है, जो एक अद्वितीय सत्र कुकी उत्पन्न करता है, जिसे उपयोगकर्ता तब आपके कंप्यूटर गेम सर्वर में पारित कर सकता है। सर्वर तब लॉगिन सिस्टम पूछता है यदि कुकी अनुरोधित उपयोगकर्ता के लिए मान्य है। आम तौर पर सेकंड (15-30, उदाहरण के लिए) के आदेश पर कुकी पर बहुत कम समय समाप्त होता है, और इसे आम तौर पर एक बार अमान्य कर दिया जाता है, जिससे रिप्ले हमलों को असंभव बना दिया जाता है।
ध्यान दें कि HTTPS मेरा सबसे अनुशंसित विकल्प है यदि आप क्लाइंट के अंदर से ही तार पर भुगतान की जानकारी भेजने की योजना बनाते हैं। हालाँकि, इसके लिए थर्ड-पार्टी का उपयोग करना बेहतर है। अगर आपको लगता है कि पासवर्ड को सरल बनाना बहुत आसान काम है, तो आप क्रेडिट कार्ड नंबर के भंडारण और प्रसंस्करण के लिए पीसीआई अनुपालन नियमों को न्यूनतम (और ईमानदारी से अपर्याप्त) पूरा करने की कोशिश करने के बारे में सोचना भी नहीं चाहते हैं। यदि आपके पास उपयोगकर्ता विश्वसनीय तृतीय-पक्ष भुगतान सेवाओं का उपयोग करते हैं, तो आप बेहतर बिक्री से आगे निकल जाएंगे, जो पहले से ही फ़ाइल के साथ हैं।
मुख्य गेम सर्वर से आपकी लॉगिन सेवा को अलग करने का एक मजबूत लाभ यह है कि यह बाहरी कार्यक्षमता को गेम से स्वतंत्र उपयोगकर्ता खातों से बंधा होने की अनुमति देता है। हो सकता है कि आपकी वेबसाइट पर कुछ खाता सुविधाएँ (अवतारों या ऐसे देखने), या शायद आप अपने खातों में फेसबुक खातों को जोड़ने की अनुमति दें, या शायद आपके पास एक ही अंतर्निहित खाता प्लेटफ़ॉर्म साझा करने वाले कई गेम हैं (जैसे, गैलेक्सी ऑन वॉर ऑफ़ मास इफेक्ट्स) 3)।
प्रमाणीकरण के लिए HTTPS का उपयोग कर एक लोकप्रिय उदाहरण गेम Minecraft है।
मूल-ग्राहक खेलों के साथ थर्ड-पार्टी वेब ऑथेंटिकेशन
मूल ग्राहक के साथ फेसबुक कनेक्ट या Google जैसी तृतीय-पक्ष सेवाओं का उपयोग करना संभव है। उदाहरण के लिए फेसबुक में iOS और Android के लिए एक देशी एसडीके है, जैसा कि Google करता है। इसी तरह कुछ सेवाओं में पारंपरिक पीसी ग्राहकों के लिए देशी एसडीके हैं।
यदि लक्ष्य सेवा में मूल SDK नहीं है और उसे वेब ब्राउज़र के उपयोग की आवश्यकता है, तो आप अपने गेम में ब्राउज़र को एम्बेड कर सकते हैं। हालांकि, कुछ उपयोगकर्ता लॉगिन जानकारी दर्ज करने के लिए एक एम्बेडेड ब्राउज़र का उपयोग करने के बारे में अविश्वास कर सकते हैं।
आप बाहरी ब्राउज़र का भी उपयोग कर सकते हैं। इसे बंद करने के कुछ तरीके हैं। कुछ को दूसरों की तुलना में थोड़ा अधिक ओएस-एकीकरण की आवश्यकता होती है। कुछ को आपको अपने मुख्य गेम सर्वर के साथ एक बाहरी वेब सेवा (या कम से कम पहुंच योग्य) के साथ चलने की आवश्यकता होती है। ध्यान दें कि चूंकि फेसबुक और Google को आम तौर पर एक URL की आवश्यकता होती है जो प्रमाणित होता है, इसलिए आपको (लगभग) सभी मामलों में इन प्रोटोकॉल का उपयोग करने के लिए एक सार्वजनिक वेबसाइट लैंडिंग पृष्ठ की आवश्यकता होगी।
सबसे मूर्खतापूर्ण और विश्वसनीय, अगर काफी आसान नहीं है, तो अपने मुख्य वेबसाइट के माध्यम से अपने ग्राहक से अपने लॉगिन अनुरोध को उछाल देना है। आपका क्लाइंट एक मुख्य अतिथि सर्वर को एक प्रमाणित अतिथि उपयोगकर्ता के रूप में जोड़ता है और एक अद्वितीय सत्र टोकन प्राप्त करता है। गेम सर्वर क्लाइंट को इस स्थिति में वास्तव में बहुत कुछ करने की अनुमति नहीं देता है; खेल यह नहीं जानता कि खिलाड़ी कौन है, इसलिए खिलाड़ी अभी तक चैट नहीं कर सकता, मैच शुरू कर सकता है, या इसी तरह।
क्लाइंट तब आपके गेम के डोमेन के लॉगिन URL की ओर इशारा करते हुए बाहरी ब्राउज़र लॉन्च करता है, जो इस सत्र टोकन को URL में एक पैरामीटर के रूप में पारित करता है। साइट तब फेसबुक / Google के लिए सामान्य लॉगिन हैंडशेक से गुजरती है।
इस बिंदु पर, आपका वेबसर्वर जानता है कि उपयोगकर्ता ने लॉग इन कर लिया है, और वह सत्र टोकन के साथ इसे क्लाइंट से प्राप्त कर सकता है। यह सत्यापन खेल सर्वर के लिए संचारित किया जा सकता है, ग्राहक के अनधिकृत अतिथि कनेक्शन को एक प्रमाणित उपयोगकर्ता सत्र में बढ़ा सकता है। यदि संभव हो तो वेबसर्वर गेम सर्वर के साथ सीधे संवाद करके ऐसा किया जा सकता है। या गेम सर्वर समय-समय पर लंबित अतिथि कनेक्शन की प्रमाणीकरण स्थिति के लिए वेबसर्वर का चुनाव कर सकता है। या क्लाइंट समय-समय पर वेबसर्वर को देखने के लिए देख सकता है कि लॉगिन पूरा हुआ है या नहीं, जब यह है, तो वेबसर्वर से सत्यापन का अनुरोध करने के लिए गेम सर्वर को संकेत दें।
इन सभी के लिए आवश्यक है कि आपका गेम सर्वर और वेबसर्वर संचार कर सकें, लेकिन किसी भी थर्ड पार्टी ऑथेंटिकेशन सेवा को आपके गेम सर्वर को बाहरी दुनिया के साथ संवाद करने में सक्षम होना पड़ेगा, इसलिए यह कोई आश्चर्य की बात नहीं है।
यह प्रमाणीकरण विधि कुछ छोटे-से-मध्यम आकार के MMOs में पाई जाती है।
ध्यान दें कि यह सब बाहरी सेवा के माध्यम से भुगतान अनुरोध करने के लिए भी काम करता है, जैसे कि पेपाल, अमेज़ॅन पेमेंट, Google वॉलेट आदि।
डायरेक्ट टीएलएस कनेक्शन
एक कस्टम स्ट्रीम प्रोटोकॉल पर टीएलएस सत्र शुरू करना बहुत मुश्किल नहीं है। OpenSSL, GnuTLS, NSS, और विभिन्न OS- विशिष्ट लाइब्रेरी जैसी लाइब्रेरी एक स्ट्रीम रैपर एपीआई प्रदान करती हैं जो एक निम्न-स्तरीय परिवहन / प्रोटोकॉल पर परतें बनाती हैं। आपको आमतौर पर रैपर एपीआई के माध्यम से बाइट्स खिलाने की जरूरत होती है और यह हैंडशेक और एन्क्रिप्शन के साथ काम करता है।
यहाँ मुश्किल भागों सुनिश्चित कर रहे हैं कि आपके TLS का उपयोग सुरक्षित है। उदाहरण के लिए सामान्य पुस्तकालयों में से कुछ डिफ़ॉल्ट रूप से एक विश्वसनीय प्राधिकारी से वैध हस्ताक्षरित प्रमाण पत्र की आवश्यकता होगी। कुछ सामान्य पुस्तकालयों की आवश्यकता होती है, लेकिन डिफ़ॉल्ट रूप से किसी भी अधिकारी पर भरोसा नहीं करते हैं। उनमें से कुछ को यह प्रमाणित करने की आवश्यकता नहीं है कि प्रमाणपत्र बिल्कुल वैध है।
यह अनुशंसा की जाती है कि आपको हमेशा एक वैध प्रमाणपत्र की आवश्यकता होती है। अवैध कटाई को रोकने के लिए एक हमलावर को अनुमति नहीं दी जाएगी जो केवल एक पासवर्ड चोरी करने के लिए उत्सुक है, लेकिन यह अभी भी मानव-में-मध्य हमलों की अनुमति देगा।
इस दृष्टिकोण को अधिकतम सुरक्षा की अनुमति देते हुए बाहरी निर्भरता के संदर्भ में पूर्ण रूप से कम से कम आवश्यकता होती है।
इसका उपयोग करने वाले खेलों के उदाहरणों में अब सबसे बड़े पारंपरिक MMOs शामिल हैं।
सुरक्षित (ईश) पारंपरिक खेल
गेम्स जो एक अलग सेवा का उपयोग नहीं करते हैं और टीएलएस का उपयोग नहीं करते हैं, उन्हें आमतौर पर अपने मुख्य गेम प्रोटोकॉल में किसी प्रकार के गैर-आधारित लॉगिन प्रोटोकॉल को लागू करना पड़ता है। इस विधि के साथ, सर्वर एक यादृच्छिक संख्या (एक गैर) उत्पन्न करता है और क्लाइंट को भेजता है। क्लाइंट तब उपयोगकर्ता के पासवर्ड (और उपयोगकर्ता नाम, संभवतः कुछ अन्य डेटा) के साथ गैर-हैश करता है और सर्वर को वह प्रतिक्रिया भेजता है। सर्वर तब इस हैशेड मान की तुलना उस फ़ाइल में मौजूद क्रेडेंशियल से करता है। यह वायर पर उपयोगकर्ता के पासवर्ड को सुरक्षित रखता है और यह सुनिश्चित करता है कि आप हैशेड पासवर्ड पर कई अन्य कमजोर हैश-आधारित लॉगिन योजनाओं की तरह एक साधारण रीप्ले हमले का उपयोग नहीं कर सकते।
एक समस्या यह है कि उपयोगकर्ता के पास इस प्रोटोकॉल पर सुरक्षित रूप से सेवा के लिए एक नया पासवर्ड सबमिट करने का कोई तरीका नहीं है। सामान्य कार्यान्वयन भी सर्वर पर उपयोगकर्ता के पासवर्ड को प्लेनटेक्स्ट में संग्रहीत करते हैं, जो एक भयानक अभ्यास है (यदि आपका सर्वर हैक हो जाता है, तो आपके उपयोगकर्ता को शायद उसका ईमेल / फेसबुक / बैंक पासवर्ड चोरी हो गया था, क्योंकि वह आपके गेम के लिए समान पासवर्ड का उपयोग कर रहा था। हर जगह, क्योंकि उपयोगकर्ता ऐसा करते हैं)।
उस मूल लॉगिन योजना के वर्धित संस्करण हैं। सबसे बुनियादी - हालांकि अभी भी आदर्श रूप से सुरक्षित नहीं है - सर्वर के लिए लॉगिन के दौरान नॉन वैल्यू के साथ पासवर्ड हैश नमक भेजना है। यह सर्वर को हैश (और नमकीन) पासवर्ड को सुरक्षित रूप से संग्रहीत करने की अनुमति देता है, जबकि क्लाइंट लॉगिन के दौरान उसी हैश को उत्पन्न करने की अनुमति देता है। यह एक हमलावर को किसी विशेष उपयोगकर्ता के पासवर्ड के लिए नमक प्राप्त करने की अनुमति देता है, लेकिन मूल हैशेड पासवर्ड (जो लॉगिन के दौरान तार पर नहीं भेजा जाता है) प्राप्त किए बिना यह विशेष रूप से उपयोगी नहीं है। पासवर्ड बनाने / अपडेट करने के दौरान, क्लाइंट पूरे हैशेड पासवर्ड (नमक के साथ) भेजता है, जिसे हमलावर सूँघ सकता है। यदि उपयोग किया गया हैश फ़ंक्शन पर्याप्त रूप से मजबूत है (कहते हैं, श -2 / 512) तो शुद्ध ब्रूट फोर्सिंग संभव नहीं है, हालाँकि हमलावर अभी भी आसानी से कमजोर पासवर्ड को दबा सकता है (यही कारण है कि कुछ न्यूनतम पासवर्ड लंबाई, अक्षरों / संख्याओं / प्रतीकों का न्यूनतम वितरण और ज्ञात / स्पष्ट / कमजोर पासवर्ड के शब्दकोश की तुलना करना महत्वपूर्ण है)। तथ्य यह है कि हमलावर अभी भी हैशेड पासवर्ड प्राप्त कर सकता है यही कारण है कि यह अभी भी सुरक्षित, एन्क्रिप्टेड चैनल पर पूरे पासवर्ड एक्सचेंज करने के लिए अधिक सुरक्षित है।
कई लोकप्रिय गेम नेटवर्किंग लाइब्रेरी इस प्रोटोकॉल के कुछ वैकल्पिक रूप को लागू करती हैं। मेरा मानना है कि स्मार्टफॉक्स एक ऐसा उदाहरण है, हालांकि मैंने इसे गहराई से नहीं देखा है (मैं आमतौर पर इस तरह की किसी भी पुस्तकालय नीति को अनदेखा करता हूं और HTTPS पद्धति का उपयोग करता हूं, क्योंकि यह लागू करने के लिए सरल है और काफी मजबूत है)। कई शुरुआती नॉन-वेब इंटरनेट गेम्स ने भी इस दृष्टिकोण का उपयोग किया, विशेष रूप से स्टीम, एक्सबीएल से पहले, और इसी तरह चारों ओर आया।
अनसिक्योर ट्रेडिशनल गेम्स
बहुत सारे खेल दुर्भाग्य से बस प्लेनटेक्स्ट में उपयोगकर्ता नाम / पासवर्ड भेजते हैं। हो सकता है कि उनके पास पासवर्ड है, जो उपयोगकर्ताओं की वास्तविक पासवर्ड (लगभग अच्छी तरह से पर्याप्त नहीं) की रक्षा करता है, लेकिन फिर से खेलना हमले को खेल सेवा में तुच्छ बनाता है।
यह मत करो। यह गैर जिम्मेदाराना और आलसी है। 1990 की इंटरनेट naiveté है कि इन लॉगिन तरीकों को लोकप्रिय बनाया अब एक व्यवहार्य बहाना है।
कई शुरुआती प्री-फेसबुक फ्लैश और वेब गेम्स ने यह तरीका अपनाया। मुझे अपने सिर के ऊपर से किसी विशिष्ट उदाहरण का पता नहीं है; मुझे विश्वास है कि वे सभी लंबे समय से मृत हैं, लेकिन दुनिया अभी भी भाग्यशाली नहीं है।
कोई प्रमाणीकरण नहीं
ज्यादातर खेल सिर्फ प्रमाणीकरण नहीं करते हैं। खिलाड़ी जोड़ता है, विशिष्ट रूप से खुद को पहचानने के लिए कुछ संभाल भेजता है, और एक मैच शुरू होता है। कोई वैश्विक सर्वर नहीं है जो यह पुष्टि करने की कोशिश करता है कि केवल एक वास्तविक मानव को कभी भी "कैप्टनमिस्टरडूड" होने का दावा करने की अनुमति है। स्थानीय सर्वर केवल यह सुनिश्चित करता है कि वर्तमान में कनेक्ट किए गए खिलाड़ी के पास केवल कोई विशेष हैंडल है, और वह इसका अंत है। स्थानीय सर्वर परेशानी पैदा करने वालों के लिए नाम-आधारित और आईपी-आधारित ब्लैकलिस्टिंग का उपयोग करते हैं। यह आज भी एफपीएस मृत्युंजय शैली के खेल के लिए आम है।
यदि आपको खातों के लिए किसी भी स्थायी स्थिति की आवश्यकता नहीं है, तो यह सबसे आसान समाधान है, और काफी "सुरक्षित" है क्योंकि वास्तव में हैक या चोरी करने के लिए कुछ भी नहीं है। जाहिर है यह बहुत अच्छा काम नहीं करता है यदि आपको गेम सत्रों के बीच खाते की जानकारी संग्रहीत करने की आवश्यकता है।
क्वेक "प्रमाणीकरण" उपयोगकर्ताओं की इस पद्धति का उपयोग करते हुए एक खेल का एक उदाहरण है।