उपयोगकर्ताओं को कैसे आश्वस्त करें कि वेबसाइट और पासवर्ड सुरक्षित हैं [बंद]


15

विश्वसनीय वेबसाइटों पर मुझे हमेशा "सभी डेटा एन्क्रिप्टेड है" या "सभी पासवर्ड 128 बिट एन्क्रिप्शन का उपयोग करके एन्क्रिप्टेड हैं" और आदि जैसे दावे दिखाई देते हैं, हालांकि मैं कभी भी इस तरह के दावे के साथ नहीं आया हूं जैसे "सभी पासवर्ड हैशेड हैं।"

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

प्रश्न: क्या यह कहना ठीक है कि "सभी पासवर्ड एन्क्रिप्टेड और सुरक्षित हैं" आराम शब्द "एन्क्रिप्शन"? या क्या कोई वैकल्पिक संदेश है जो मुझे प्रदान करना चाहिए?

एक साइड नोट पर, मैं एन्क्रिप्शन और पासवर्ड हैशिंग के लिए नया हूं और मैं सोच रहा था कि क्या यह अभी के लिए सुरक्षित होगा क्योंकि मैं अपनी साइट लॉन्च करूंगा। मैं उपयोगकर्ताओं को यह बताना नहीं चाहता कि यह सुरक्षित है यदि यह नहीं है। कोई भी सूचना अत्यधिक सराहनीय होगी। धन्यवाद।


7
व्यक्तिगत रूप से मैं संचार के बारे में बहुत अधिक चिंता नहीं करूंगा: आप जो भी करते हैं उसका तकनीकी विवरण लिखें, अक्सर पूछे जाने वाले प्रश्न में गहराई से दफन जहां तकनीकी-दिमाग मिलेगा। किसी और को वास्तव में वैसे भी परवाह नहीं है। अधिक महत्वपूर्ण बात: सुनिश्चित करें कि आप सही काम करते हैं (यदि आप नए हैं तो यह कठिन है, लेकिन कम से कम आप कोशिश कर रहे हैं!)। अपने स्वयं के हैशिंग का निर्माण न करें, bcrypt जैसी किसी चीज़ का उपयोग करें ।
जोकिम सॉर

4
खैर, सही बात यह है कि लॉगिन को फ़ेडरेट करें और उपयोगकर्ताओं को किसी अन्य उपयोगकर्ता नाम और पासवर्ड से परेशान न करें।
Jan Hudec

1
OpenID अच्छा है, लेकिन उपयोगकर्ता नाम / पासवर्क भी ठीक है। मुझे नहीं लगता कि आपकी समस्या उपयोगकर्ताओं को मनाने के लिए है कि आपकी साइट सुरक्षित है। चूंकि आप अनुभवहीन हैं, यह आपके पास कुछ ऐसा करने का वादा करने जैसा है। बस सामान्य मानकों को लागू करें - आप पेशेवर हैकर्स को आने से नहीं रोकेंगे, लेकिन कोई भी आपको दोष नहीं दे सकता है।
लॉन्ग

3
@ कोर्डपम्प वास्तव में। पासवर्ड हैशिंग के लिए SHA-512 का उपयोग करना ठीक नहीं है। यह ठीक नहीं है"।
थॉमस

3
मैं शायद यह सुनिश्चित करने के लिए सूचना सुरक्षा पर कोई भी अनुवर्ती प्रश्न पूछने के लायक हूं कि आप बहुत अच्छे से मिल सकें, तारीख सलाह तक। (इसका मतलब यह नहीं है कि आपको यहाँ बुरी सलाह मिल रही है, बस यह कि हम सुरक्षा पेशेवर नहीं हैं)।
ChrisF

जवाबों:


22
  1. उपयोगकर्ताओं को परवाह नहीं है।

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

  2. लगभग हर मामले में मैंने ऐसे संदेश देखे हैं, वे भ्रामक थे। सबसे प्रफुल्लित करने वाला एक वेबसाइट था, जिसमें हर पेज पर "सैन्य-ग्रेड सुरक्षित" -स्टाइल लेबल थे। एक अलर्ट बता रहा था कि HTTP प्रमाणपत्र अमान्य है। लॉगऑन फॉर्म पर एक SQL इंजेक्शन था। कुछ हफ्ते बाद, वेबसाइट हैक हो गई, फिर हमेशा के लिए गायब हो गई।

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

    यह उन "W3C वैध XHTML" लेबल की तरह है। वे आम तौर पर उन वेबसाइटों पर क्यों लगाए जाते हैं, जहां होम पेज में भी कम से कम दर्जनों त्रुटियां और कोड होते हैं <DIV COLOR='red'>?

यदि आप अभी भी उपयोगकर्ताओं को आश्वस्त करना चाहते हैं, तो आप कुछ ऐसा डाल सकते हैं:

आपके पासवर्ड सुरक्षित रखे गए हैं। याद रखें कि हम आपका पासवर्ड नहीं देख सकते हैं और कभी भी आपको ई-मेल भेजने के लिए नहीं कहेंगे।

लेकिन स्पष्ट रूप से, "अपना पासवर्ड रीसेट करें" फ़ॉर्म "मैं अपना पासवर्ड भूल गया, ई-मेल द्वारा मुझे भेजें" किसी भी शब्द की तुलना में बहुत अधिक आश्वस्त है।

विभिन्न टिप्पणियों से संकेत:

  • पहिया को सुदृढ़ न करें: OpenID का उपयोग करें। इस तरह, आप हैश को स्टोर भी नहीं करते हैं।

    स्रोत: जैन हुदेक द्वारा टिप्पणी

  • चूंकि आप एक छात्र हैं, इसलिए अपनी परियोजना का स्रोत खोलें। चूंकि आपकी चिंता यह है: "मैं नहीं चाहता कि उपयोगकर्ता यह सोचें कि उनके पासवर्ड सुरक्षित नहीं हैं क्योंकि स्कूल के कुछ बच्चों ने इसे डिज़ाइन किया है।" , स्रोत कोड को पढ़कर, जांच करने में सक्षम होने के अलावा और अधिक आश्वस्त करने वाला कुछ नहीं है, यह एक कुशल डेवलपर द्वारा लिखा गया था जो सुरक्षा की परवाह करता है।

    स्रोत: जान डॉगजेन द्वारा टिप्पणी


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

3
@ user2698818 आपको सुरक्षा के लिए क्या करना चाहिए, इसके बारे में विस्तार से वर्णन करते हुए एक प्रश्न पोस्ट करें और पूछें कि क्या यह सुरक्षित है (पर्याप्त)। अच्छी सुरक्षा पूरी तरह से सार्वजनिक हो सकती है।
Jan Doggen

@ user2698818: ठीक है। मेरे उत्तर का संपादन किया।
आर्सेनी मूरज़ेंको

6
@JanDoggen: ठीक है, क्या वह करना चाहिए कर रही एक का उपयोग है मौजूदा सुरक्षा प्रणाली है कि किसी और के लिए बनाया गया और पूछा, "यह काफी सुरक्षित है।" अधिमानतः एक जहां यह सवाल कुछ समय के लिए खड़ा हुआ है और खेतों में कई विशेषज्ञों का ध्यान गया है;;
जोआचिम सॉयर

12

पहली बार में पासवर्ड स्टोर न करें! स्टैक एक्सचेंज के उदाहरण का पालन करें और उपयोगकर्ताओं को ओपनआईडी के माध्यम से प्रमाणीकरण प्रदान करने वाली किसी अन्य साइट पर उनकी पहचान के साथ लॉग इन करें । कार्यान्वयन सबसे आम वेब फ्रेमवर्क के लिए स्वतंत्र रूप से उपलब्ध हैं।

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

यह संवेदनशील सूचना के संचय से बचाता है (आप सबसे शायद अभी भी दुकान अनुमतियाँ करना होगा, लेकिन वे नहीं कर रहे हैं कि महत्वपूर्ण) इसलिए समग्र जीत और अभी तक एक और उपयोगकर्ता नाम और पासवर्ड याद करने के लिए होने से उपयोगकर्ताओं,।


1
कृपया मुझे बताएं कि आपने कौन सी साइटें बनाई हैं, इसलिए मैं उनसे बच सकता हूं यदि आप अनुमति को सुरक्षा-महत्वपूर्ण नहीं मानते हैं।
orlp

1
क्या होगा अगर आवश्यकता पासवर्ड स्टोर करने के लिए है। साथ ही सवाल विशेष रूप से उन्हें संग्रहीत करने के बारे में पूछता है।
पायोत्र कुला

3
@ppumkin: इस तरह के कई सवाल हैं "मैं X को Y करने के लिए कैसे उपयोग करता हूं" जहां सबसे अच्छा जवाब है "आप Z का उपयोग करते हैं"। यदि आप सहमत नहीं हैं, तो बस बेहतर उत्तर दें ;-)।
जन हडेक

3
@ppumkin एक सादृश्य का उपयोग करने के लिए: "मैं अपनी मुट्ठी के साथ एक चट्टान को तोड़ने की कोशिश कर रहा हूं, मुझे किस दस्ताने का उपयोग करना चाहिए?" 19 वें जर्मन कैवेलरी गौंटलेट्स देने से पहले जाँच लें कि उन्हें छेनी की जानकारी है या नहीं।
डेवॉर्डे

1
मैं OpenID सुझाव देने के लिए बहुत जल्दी होने से बचूंगा। हां, यह बहुत अच्छा है, लेकिन यह आम तौर पर सबसे अच्छा काम करता है यदि आप कई OpenID / OAuth प्रदाताओं का समर्थन करते हैं। बहुत सारे तकनीकी फ़ोरम, ब्लॉग, क्यू एंड अस आदि हैं जहाँ आपको फेसबुक के ओआईडी प्रदाता के माध्यम से लॉग इन करना होगा और किसी अन्य का उपयोग नहीं कर सकते। मैं एक ऐसे कार्य नेटवर्क पर हूँ जो फेसबुक डोमेन को ब्लॉक करता है, और इसलिए मैं उन साइटों के साथ काम नहीं कर सकता। यदि आप OID का समर्थन करने जा रहे हैं, और केवल अब के लिए एक का उपयोग करने जा रहे हैं, तो एक प्रदाता चुनें जो आपके लक्षित दर्शकों के बीच लोकप्रिय है, और एक sysadmin द्वारा अवरुद्ध होने की संभावना नहीं है। Google और Windows Live अच्छे विकल्प हैं।
21

2

कह रही है:

"यह सुरक्षित है।"

एक व्यक्तिगत निर्णय है जो आप कुछ तकनीकी तथ्यों या प्रक्रियाओं के बारे में करते हैं, और यह निर्णय उस समय तक सीमित है जो आप स्वयं उस समय सुरक्षा के बारे में जानते हैं। लेकिन क्या आप बिना किसी संदेह के गारंटी दे सकते हैं कि आपका एन्क्रिप्शन, स्टोरेज मेथड, आदि किसी भी तरह के हमले को पकड़ लेंगे, यहां तक ​​कि जिनके बारे में आप नहीं जानते, या जिनके बारे में अभी तक पता नहीं है?

अर्थ: यह कथन आपके पुराने होने के खतरे में है, शायद आपके जानकारी के बिना भी।

इसलिए मैं @JoachimSauer की उपरोक्त टिप्पणी से सहमत हूं: आप जो भी करते हैं उसका वर्णन करें, आप उपयोगकर्ता की जानकारी कैसे बचाते हैं, और उपयोगकर्ताओं को बताएं कि यह आपकी सेवा को कैसे सुरक्षित बनाने वाला है । फिर यूजर्स को खुद के लिए जज करने दें।


नहीं, "यह सुरक्षित है" एक "व्यक्तिगत" या व्यक्तिपरक कथन नहीं है, यह मेरे लिए "यह सुंदर है" जैसा नहीं है । यह वास्तव में एक शब्दार्थक खाली कथन है, "किस संदर्भ में" या "किस हमले से सुरक्षित है" या "किस संदर्भ में किस स्तर पर" निर्दिष्ट किए बिना। यदि आपके पूरे विवरण में "यह सुरक्षित है" है, तो इसे टाइप करने से पहले यह पुराना हो जाता है, और यह अत्यधिक संभावना है कि आपको इसके बारे में जानकारी नहीं है। मैं पिछले भाग पर सहमत हूँ, यह सब विवरण के बारे में है।
AviD 10

@ एवीडी: शायद आप शब्दों के मेरे विशिष्ट विकल्प में बहुत अधिक पढ़ते हैं। हां, यह कहना कि बिना अधिक विवरण दिए कुछ "सुरक्षित" है, व्यर्थ है। लेकिन मुझे विश्वास है कि यह भी एक व्यक्तिगत निर्णय है, क्योंकि हर किसी के पास "सुरक्षा" के लिए समान भावना नहीं है और मांग करता है: ए जो पर्याप्त सुरक्षित करता है वह बी को असुरक्षित महसूस कर सकता है। इसलिए यह कहना कि "कुछ सुरक्षित है" बताता है कि जो व्यक्ति "इसे सुरक्षित पाता है" बयान करता है। और यह एक ही वजन के साथ एक तर्क नहीं है जैसे कि किसी को प्रासंगिक तथ्य देना, और उन्हें अपना निष्कर्ष निकालना।
स्टैक

अधिकार के संबंध में, "मैं क्या आवश्यकताओं, सुरक्षा प्रोफ़ाइल, जोखिमों, आदि के लिए था, फिर भी एक व्यक्तिगत निर्णय नहीं है, लेकिन शायद" व्यक्तिगत "से आपका मतलब क्या है" संदर्भ "से मेरा मतलब है। "सुरक्षित" है एक कठिन विज्ञान मीट्रिक नहीं एक नरम निरर्थक "महसूस"। लेकिन हाँ, जैसा कि आप कहते हैं, मुझे यह नहीं बताएं कि यह "सुरक्षित" है, मुझे बताएं कि आपने इसे बनाने के लिए क्या किया।
AviD

@AviD: ठीक है। मैं नहीं किसी भी आगे तर्क बुरी तरह पीटना करते हुए कहा है कि सुरक्षा के अलावा होगा है एक निरर्थक लग रहा है, भी। यह निश्चित रूप से अधिक से अधिक है, लेकिन जब सवाल उपयोगकर्ताओं को "आश्वस्त करने" (प्रश्न शीर्षक देखें) के बारे में है, तो इच्छा-वाश महसूस क्या अंत में मायने रखता है।
स्टैकएक्स

1

यह वास्तव में आपकी विशिष्ट वेबसाइट के संदर्भ पर निर्भर करता है।

उदाहरण के लिए, यदि यह एक उपभोक्ता वेबसाइट है, तो संभावना यह है कि उनमें से ज्यादातर केवल अपने पासवर्ड (शायद), वित्तीय / स्वास्थ्य जानकारी (निर्भर), और उनकी निजी जानकारी जैसे कि चित्र (हाहा, हाँ सही है ...) के बारे में परवाह करेंगे ।

यदि यह एक व्यावसायिक अनुप्रयोग है, तो पूरी साइट की सुरक्षा प्रासंगिक है, न कि केवल पासवर्ड। इसी तरह, यह इस बात पर निर्भर करता है कि आपके लक्षित उपयोगकर्ता कौन हैं - अत्यधिक तकनीकी / इतने तकनीकी नहीं, आदि।

यह सब संदर्भ बहुत परिभाषित करता है कि आपको क्या संवाद करना चाहिए, और किस स्तर के आश्वासन की आवश्यकता है।

उदाहरण के लिए, गैर-तकनीकी उपभोक्ताओं के लिए, कुछ सामान्य, सरल टिप्पणियां, जैसे:

इस साइट को अत्याधुनिक सुरक्षा तकनीकों का उपयोग करके बनाया गया है। आपका पासवर्ड हमेशा एन्क्रिप्ट किया जाता है, और हम कभी भी आपकी तस्वीरों को एनएसए में नहीं भेजेंगे।

(और, जैसा कि अन्य लोगों ने कहा, आप बेहतर बंद भी नहीं कर रहे हैं होने पासवर्ड बिल्कुल, OpenId या OAuth जैसे कुछ मानक का उपयोग करें।)

अत्यधिक तकनीकी व्यवसायों के लिए, आप तकनीकी और प्रक्रियात्मक विवरणों का एक पूरा पृष्ठ रखना चाहेंगे, जैसे:

हमने अपने विकास और परिनियोजन प्रक्रिया के दौरान एक पूर्ण SDL (सुरक्षित विकास जीवनचक्र) लागू किया है।
...
हमारी सुरक्षा वास्तुकला है ... यह लाभ देता है ...
हम सुरक्षित कोडिंग सुनिश्चित करते हैं ... जैसे ... हम इन और उन परीक्षणों का प्रदर्शन करते हैं।
हमारी क्रिप्टोग्राफी में ये एल्गोरिदम शामिल हैं ... और ... हम जो भी उद्योग विनियमन की आवश्यकता के अनुरूप हैं, और आपके लिए प्रमाणित ...
हमारी सुरक्षा इस स्वतंत्र 3 पार्टी सलाहकार द्वारा सत्यापित है।
...
अधिक जानकारी के लिए, और हमारी नीतियों की समीक्षा करने या एक स्वतंत्र ऑडिट की व्यवस्था करने के लिए, कृपया विपणन विभाग के साथ चर्चा करें।

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

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

जाहिर है कि यह उस छोटे प्रतिशत के लिए है जो देखभाल करता है - आपको स्मार्ट उपयोगकर्ताओं को वह करने में सक्षम होना चाहिए जो उन्हें सही हो, उन्हें उनकी आवश्यक जानकारी दे, और उन्हें वह शिक्षा प्रदान करें जो वे माँग सकते हैं।
यदि आप नहीं करते हैं, जब वह गलत हो जाता है, तो अन्य 98% अचानक जाग जाएगा और क्रोधित हो जाएगा।
("यकीन है, मुझे पता था कि मुझे अपने चित्रों को देखने के लिए पासवर्ड की आवश्यकता नहीं है, लेकिन मुझे नहीं लगता कि कोई और भी हमें देख सकता है !!")


0

यदि आप चाहते हैं कि आपका सिस्टम सुरक्षित रहे, तो पासवर्ड एल्गोरिथ्म की ताकत निरर्थक है - अधिकांश हैकर बिना किसी समय के पासवर्ड को क्रैक कर सकते हैं, खासकर यदि चुना गया पासवर्ड छोटा है या जेनेरिक शब्दों से युक्त है, जिसे हैकर ने पहले ही क्रैक किया है और संग्रहीत किया है "usiong इंद्रधनुष टेबल और इसी तरह। बहुत अधिक जानकारी के लिए पासवर्ड क्रैकिंग पर ArsTechnica का लेख पढ़ें ।

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

कोड के लिए यह उतना बुरा नहीं था जितना आप सोच सकते हैं, एक बार जब आप आर्किटेक्चर और प्रत्येक टियर को अलग करना जानते थे, तो इसके लिए कोड करना काफी आसान था।


0

आप ग्रह पर सबसे सुरक्षित साइट विकसित कर सकते हैं और वास्तव में खराब उपयोगकर्ता अनुभव कर सकते हैं। उपयोगकर्ता मान लेंगे कि आपकी साइट असुरक्षित है।

आप ग्रह पर कम से कम सुरक्षित साइट बना सकते हैं और अद्भुत उपयोगकर्ता अनुभव प्राप्त कर सकते हैं। उपयोगकर्ता मान लेंगे कि आपकी साइट सुरक्षित है। कम से कम जब तक यह शाम की खबर पर प्रकट नहीं होता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.