किसी वेबसाइट के एडमिन सेक्शन को सुरक्षित करने के लिए सर्वोत्तम अभ्यास क्या हैं? [बन्द है]

Question

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

निश्चित रूप से स्पष्ट चीजें हैं, जैसे कि एसएसएल का उपयोग करना और सभी एक्सेस को लॉग इन करना, लेकिन मैं सोच रहा हूं कि इन बुनियादी चरणों के ऊपर लोग बार को कहां सेट करना चाहते हैं।

उदाहरण के लिए:

• क्या आप केवल उसी प्रमाणीकरण तंत्र पर निर्भर हैं जो आप सामान्य उपयोगकर्ताओं के लिए उपयोग करते हैं? यदि नहीं, तो क्या?
• क्या आप उसी 'एप्लिकेशन डोमेन' में एडमिन सेक्शन चला रहे हैं?
• व्यवस्थापन अनुभाग को अनदेखा करने के लिए आप क्या कदम उठाते हैं? (या आप पूरी 'अस्पष्टता' को अस्वीकार करते हैं)

---

अब तक, उत्तरदाताओं के सुझावों में शामिल हैं:

• जानवर बल के हमलों को रोकने के लिए प्रत्येक व्यवस्थापक पासवर्ड की जांच में एक कृत्रिम सर्वर-साइड ठहराव का परिचय [डेवलपर कला]
• एक ही DB तालिका का उपयोग करके उपयोगकर्ताओं और व्यवस्थापक के लिए अलग-अलग लॉगिन पृष्ठों का उपयोग करें (XSRF को रोकने के लिए और व्यवस्थापक क्षेत्रों के लिए सत्र-चोरी देना) [चोर मास्टर]
• व्यवस्थापक क्षेत्र (जैसे .htaccess) के माध्यम से वेबसर्वर देशी प्रमाणीकरण जोड़ने पर विचार करें [चोर मास्टर]
• कई विफल व्यवस्थापन लॉगिन प्रयासों के बाद उपयोगकर्ताओं के आईपी को अवरुद्ध करने पर विचार करें [चोर मास्टर]
• असफल व्यवस्थापक लॉगिन प्रयासों के बाद कैप्चा जोड़ें [चोर मास्टर]
• उपयोगकर्ताओं के लिए और साथ ही एडिंस के लिए समान रूप से मजबूत तंत्र (उपरोक्त तकनीकों का उपयोग करके) प्रदान करें (उदाहरण के लिए विशेष रूप से उपचार न करें) [Lo'oris]
• दूसरे स्तर के प्रमाणीकरण पर विचार करें (जैसे ग्राहक प्रमाणपत्र, स्मार्ट कार्ड, कार्डस्पेस, आदि) [जोजीकी]
• केवल विश्वसनीय आईपी / डोमेन से पहुंच की अनुमति दें, यदि संभव हो तो मूल HTTP पाइपलाइन (उदाहरण के लिए HttpModules) के माध्यम से चेक जोड़ें। [JoeGeeky]
• [ASP.NET] IPrincipal और प्रिंसिपल को लॉक करें (उन्हें अपरिवर्तनीय और गैर-योग्य बनाएं ) [Joeeeeeee]
• फेडरेट राइट्स एलिवेशन - जैसे किसी भी एडमिन के राइट्स अपग्रेड होने पर अन्य ऐडमिट्स को ईमेल करता है। [JoeGeeky]
• प्रवेश के लिए ठीक-ठीक अधिकारों पर विचार करें - जैसे भूमिकाओं पर आधारित अधिकार के बजाय, प्रति व्यवस्थापक के लिए संकेतात्मक कार्यों के अधिकारों को परिभाषित करें [जोजेब]
• प्रवेश को प्रतिबंधित करना - जैसे कि व्यवस्थापक अन्य व्यवस्थापक खाते नहीं बदल सकते हैं या बना नहीं सकते हैं। इसके लिए एक लॉक-डाउन 'सुपरडामिन' क्लाइंट का उपयोग करें। [JoeGeeky]
• क्लाइंट साइड एसएसएल सर्टिफिकेट या आरएसए टाइप कीफॉब्स (इलेक्ट्रॉनिक टोकन) पर विचार करें [डैनियल पापासियन]
• यदि प्रमाणीकरण के लिए कुकीज़ का उपयोग कर रहे हैं, तो व्यवस्थापक और सामान्य पृष्ठों के लिए अलग कुकीज़ का उपयोग करें, उदाहरण के लिए एक अलग डोमेन पर व्यवस्थापक अनुभाग डालकर। [डैनियल पापासियन]
• यदि व्यावहारिक है, तो सार्वजनिक इंटरनेट से एक निजी सबनेट पर व्यवस्थापक साइट को रखने पर विचार करें। [जॉन हार्टसॉक]
• वेबसाइट / रिचर्ड जेपी ले गुएन के व्यवस्थापक / सामान्य उपयोग संदर्भों के बीच आगे बढ़ने पर, सामान्य / सत्र टिकटों को फिर से खोलें।

Comments

सिर्फ एक सोच लेकिन संभवतः व्यवस्थापक अनुभाग को सुरक्षित करने का सबसे अच्छा तरीका सार्वजनिक इंटरनेट पर नहीं है। आप केवल एक निजी सबनेट पर व्यवस्थापक साइट रखने के लिए चुन सकते हैं।

— जॉन हार्टसॉक

इनमें से कौन सा विचार आपके द्वारा निर्दिष्ट है, यह सभी उपयोगकर्ताओं के लिए लागू करने के लिए एक अच्छा विचार नहीं होगा, न कि केवल प्रवेश?

— विवियन नदी

आप Webloginproject.com पर WebLoginProject की जाँच करना चाह सकते हैं। यह एक सहयोगी लॉगिन प्रणाली है जिसे XSS, SQL इंजेक्शन, सत्र निर्धारण और CSRF भेद्यताओं के खिलाफ सुरक्षित बनाने के लिए तैयार किया गया है। एएसपी और पीएचपी में इसका स्रोत कोड है, यह बहुभाषी है और यह अच्छा दिखता है। बहुत सारे डेवलपर्स छेद को ठीक करने पर काम कर रहे हैं, इसलिए यह संभवतः उतना ही सुरक्षित है जितना इसे मिल सकता है।

— stagas

-1 के लिए बहुत गलत "मजबूत पासवर्ड" (जो वास्तव में इसके बजाय एक बहुत कमजोर पासवर्ड है) सुझाव

— o0 'शामिल है।

@ लोरिस - मुझे सच में समझ नहीं आ रहा है कि आपने इस सवाल को क्यों गलत समझा। क्या आप अस्वीकार कर रहे हैं क्योंकि मैं किसी ऐसे व्यक्ति को सुझाव देता हूं जिसके साथ आप सहमत नहीं हैं? शायद संबंधित उत्तर को नकारना अधिक रचनात्मक होगा। : / क्या आप स्पष्ट कर सकते हैं कि आपको क्या समस्या है?

— अपक्रीक

Answer 1

ये सभी अच्छे उत्तर हैं ... मैं आमतौर पर अपने प्रशासनिक खंडों के लिए कुछ अतिरिक्त परतों को जोड़ना पसंद करता हूं। हालाँकि मैंने किसी विषय पर कुछ भिन्नताओं का उपयोग किया है, वे आम तौर पर निम्नलिखित में से एक को शामिल करते हैं:

• दूसरे स्तर का प्रमाणीकरण : इसमें ग्राहक प्रमाणपत्र (एक्स। एक्स 509 सिरेट्स), स्मार्ट कार्ड, कार्डस्पेस, आदि शामिल हो सकते हैं ...
• डोमेन / आईपी प्रतिबंध : इस मामले में, केवल विश्वसनीय / सत्यापन योग्य डोमेन से आने वाले ग्राहक; जैसे कि आंतरिक सबनेट; व्यवस्थापक क्षेत्र में अनुमति दी गई है। दूरस्थ प्रवेश अक्सर विश्वसनीय वीपीएन एंट्रीपॉइंट से गुजरते हैं, इसलिए उनका सत्र सत्यापन योग्य होगा और अक्सर आरएसए कुंजी के साथ भी संरक्षित होता है। यदि आप ASP.NET का उपयोग कर रहे हैं, तो आप HTTP मॉड्यूल के माध्यम से HTTP पाइपलाइन में इन चेकों को आसानी से कर सकते हैं जो आपके एप्लिकेशन को कभी भी किसी भी अनुरोध को प्राप्त करने से रोक देगा यदि सुरक्षा जांच संतुष्ट नहीं हैं।
• IPrincipal & Principal- आधारित प्राधिकरण को लॉक किया गया : कस्टम सिद्धांत बनाना एक आम बात है, हालांकि एक सामान्य गलती उन्हें परिवर्तनीय और / या अधिकारों को असंख्य बना रही है। हालाँकि, यह न केवल एक व्यवस्थापक मुद्दा है, यह अधिक महत्वपूर्ण है क्योंकि यहां उपयोगकर्ता उपयोगकर्ताओं के उच्च अधिकार होने की संभावना है। सुनिश्चित करें कि वे अपरिवर्तनीय हैं और गणना करने योग्य नहीं हैं। इसके अतिरिक्त, सुनिश्चित करें कि प्राधिकार के लिए सभी आकलन प्राचार्य के आधार पर किए गए हैं।
• फेडरेट राइट्स एलिवेशन : जब किसी भी खाते को कुछ चुनिंदा अधिकार प्राप्त होते हैं, तो ईमेल के माध्यम से सभी व्यवस्थापक और सुरक्षा अधिकारी को तुरंत सूचित किया जाता है। यह सुनिश्चित करता है कि यदि कोई हमलावर अधिकार को बढ़ाता है तो हमें तुरंत पता चल जाता है। ये अधिकार आम तौर पर निजीकृत अधिकारों, गोपनीयता संरक्षित जानकारी, और / या वित्तीय जानकारी (उदाहरण के लिए क्रेडिट कार्ड) देखने के अधिकार के आसपास घूमते हैं।
• Admins के लिए भी : प्राधिकरण अधिकार जितना संभव हो उतना विवेकपूर्ण होना चाहिए और वास्तविक कार्यात्मक व्यवहारों को घेरना चाहिए। विशिष्ट भूमिका-आधारित सुरक्षा (RBS) दृष्टिकोण में समूह की मानसिकता होती है। सुरक्षा के दृष्टिकोण से यह सबसे अच्छा पैटर्न नहीं है। ' उपयोगकर्ता प्रबंधक ' जैसे ' समूह ' के बजाय , इसे और अधिक तोड़ने का प्रयास करें ( उदा। उपयोगकर्ता बनाएं, उपयोगकर्ता को अधिकृत करें, एलिवेट / रिवोक एक्सेस अधिकार, आदि ...)। यह प्रशासन के संदर्भ में थोड़ा अधिक ओवरहेड हो सकता है, लेकिन इससे आपको केवल उन अधिकारों को असाइन करने की सुविधा मिलती है जो वास्तव में बड़े व्यवस्थापक समूह द्वारा आवश्यक हैं। यदि पहुंच से कम से कम समझौता किया जाता है तो उन्हें सभी अधिकार नहीं मिल सकते हैं। मैं इसे .NET एक्सेस और जावा द्वारा समर्थित कोड एक्सेस सिक्योरिटी (CAS) अनुमतियों में लपेटना चाहता हूं, लेकिन यह इस उत्तर के दायरे से परे है। एक और बात ... एक ऐप में, व्यवस्थापक अन्य व्यवस्थापक खातों को बदलने या उपयोगकर्ताओं को एक व्यवस्थापक बनाने का प्रबंधन नहीं कर सकते हैं। यह केवल एक लॉक डाउन क्लाइंट के माध्यम से किया जा सकता है जिसे केवल कुछ लोग ही एक्सेस कर सकते हैं।

Answer 2

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

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

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

3-असफल लॉगिन के बाद उपयोगकर्ता के आईपी को अवरुद्ध करने या एक असफल लॉगिन के बाद कैप्चा की आवश्यकता की तरह एक जानवर-बल सुरक्षा (पहले लॉगिन के लिए नहीं है क्योंकि कानूनी उपयोगकर्ताओं के लिए बस बहुत कष्टप्रद है) भी उपयोगी हो सकता है।

Answer 3

• मैं अश्लीलता को अस्वीकार करता हूं
• एक के बजाय दो प्रमाणीकरण प्रणालियों का उपयोग करना ओवरकिल है
• प्रयासों के बीच कृत्रिम ठहराव उपयोगकर्ताओं के लिए भी किया जाना चाहिए
• उपयोगकर्ताओं के लिए असफल प्रयासों के आईपी को अवरुद्ध किया जाना चाहिए
• मजबूत पासवर्ड का उपयोग उपयोगकर्ताओं द्वारा भी किया जाना चाहिए
• यदि आप कैप्चा को ठीक मानते हैं, तो अनुमान लगाएं कि आप उपयोगकर्ताओं के लिए भी उनका उपयोग कर सकते हैं

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

Comments

जवाब के लिए धन्यवाद। व्यक्तिगत रूप से मैं असहमत हूं, उदाहरण के लिए: क्या कोई उपयोगकर्ता d ksd83, ’- 4d # rrpp0% 27 & lq (go43 $ sd {3>?) जैसे पासवर्ड से खुश होगा? और, क्या IP ब्लॉक को रीसेट नहीं किया जाएगा जो वैध उपयोगकर्ताओं द्वारा ट्रिगर किए गए हैं? भ्रामक व्यवस्थापन / ग्राहक सेवा कार्य को उत्पन्न करने में भूल जाना; व्यक्तिगत रूप से मुझे लगता है कि जोखिम के विभिन्न स्तर अलग-अलग तरीकों को सही ठहराते हैं

— उपसंहार

व्यवस्थापक पासवर्ड जटिल होना चाहिए, लेकिन अत्यधिक जटिल नहीं होना चाहिए, अन्यथा व्यवस्थापक भी इसे याद नहीं रखेगा और इसे कहीं लिख देगा (आप हर सुरक्षा नियम को धता बताने के लिए मजबूर होंगे)। असफल प्रयास के साथ अस्थायी रूप से आईपी को अवरुद्ध करना बहुत मानक है, vbulletin इसे करता है, phpbb इसे IIRC करता है, उपयोगकर्ताओं को इसका उपयोग किया जाता है।

— ओ ० '।

मैं वास्तव में सुरक्षा सर्वोत्तम प्रथाओं के लिए phpbb या vbulletin देखना नहीं चाहता हूं;)

— 12

@UpTheCric बेशक, मैं सहमत हूँ! मैं सिर्फ यह सवाल कर रहा था "आईपी ब्लॉक को रीसेट नहीं किया जा रहा है, जो वैध उपयोगकर्ताओं को ट्रिगर करने से भ्रामक व्यवस्थापक / ग्राहक सेवा कार्य करने के लिए जा रहा है" <- मुझे नहीं लगता कि यह एक समस्या होगी, क्योंकि उपयोगकर्ता पहले से ही उपयोग किए जा रहे हैं ऐसी सुविधा के लिए।

— ओ ० '।

Answer 4

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

इसलिए यदि मैं लॉग इन करता हूं, तो सामान्य उपयोगकर्ता सामग्री का एक गुच्छा करें और फिर एक व्यवस्थापक पृष्ठ पर जाएं, मेरी सत्र आईडी को पुन: उत्पन्न करें। यदि मैं फिर एक सामान्य उपयोगकर्ता पृष्ठ के व्यवस्थापक पृष्ठ (पेज) से दूर जाता हूं, तो मेरी आईडी को फिर से प्राप्त करें।

Comments

क्या आप बता सकते हैं कि यह क्या हासिल करता है?

— डेनिस पशेनोव

security.stackexchange.com/questions/1246/…

— रिचर्ड जेपी ले गुएन

मेरा मानना ​​है कि यह उतना मदद नहीं करेगा जितना आप सोचते हैं। क्योंकि यदि हमलावर सामान्य उपयोगकर्ता पृष्ठ में आपकी वर्तमान सत्र आईडी प्राप्त करने में सक्षम है, तो वह इसका उपयोग तब व्यवस्थापक पृष्ठ तक पहुंच सकता है और खुद को एक नया सत्र आईडी बना सकता है। यदि मैं गलत हूं तो मुझे सही करों।

— डेनिस पशेनोव

लेकिन हमलावर पासवर्ड के बिना व्यवस्थापक पृष्ठ तक नहीं पहुंच सकता। प्रमाणीकरण के बाद तक विशेषाधिकार स्तर में कोई बदलाव नहीं हुआ है। सत्र आईडी को पुनः प्राप्त करने में विफलता का मतलब है कि वे प्रमाणीकरण प्राप्त करने के लिए असुरक्षित रूप से बनाए गए सत्र का फिर से उपयोग कर सकते हैं।

— रिचर्ड जेपी ले गुएन

इसे अब पा लिया है। मैं सोच रहा था कि आप एक परिदृश्य का वर्णन करते हैं जहां उपयोगकर्ता को सामान्य / व्यवस्थापक संदर्भ के बीच स्विच करने पर फिर से लॉगिन नहीं करना पड़ता है।

— डेनिस पशेनोव

Answer 5

एक अच्छा व्यवस्थापक पासवर्ड है।

"123456"15-20 अक्षर कहने पर भी वर्णों, अंकों और विशेष वर्णों का क्रम नहीं, बल्कि काफी लंबा। की तरह "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>"।

जानवर बल के हमले को रोकने के लिए प्रत्येक पासवर्ड की जाँच के लिए एक ठहराव जोड़ें।

Comments

क्या आप थोड़ा समझा सकते हैं कि एक 'विराम' क्या होगा? क्या आप कुछ समय के लिए थ्रेड स्लीप (5000) की तरह कुछ करने की बात कर रहे हैं?

— earthling

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

— ओ ० '।

ओह, काश मैं इस बकवास को पत्थर की उम्र तक कम कर सकता, यह इतना बेवकूफ है, इतना गलत है ... मुझे इस तरह से गलत सूचना फैलाने वाले लोगों से नफरत है।

— ओ ० '।

@ लोरिस: यह वास्तव में क्या है जिससे आप असहमत हैं?

मैंने इसे लिखा है ... जैसे ... टिप्पणी ऊपर?

— ओ ० '।

Answer 6

यहाँ कुछ अन्य बातों पर विचार किया गया है:

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

Answer 7

हम Windows Authenticationव्यवस्थापक पहुंच के लिए उपयोग करते हैं। सामान्य अंत-उपयोगकर्ताओं पर लागू होने वाले प्रमाणीकरण को अलग रखते हुए यह व्यवस्थापक क्षेत्रों की सुरक्षा का सबसे व्यावहारिक तरीका है। सिस्टम एडमिन एडमिन यूजर एक्सेस क्रेडेंशियल्स का प्रबंधन करता है और डोमेन उपयोगकर्ता खाते पर पासवर्ड नीतियों को लागू करता है।

Answer 8

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

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

स्वाभाविक रूप से संपादन चरण केवल स्थानीय इंट्रानेट और / या वीपीएन का उपयोग करने पर उपलब्ध होना चाहिए।

यह एक ओवरकिल का एक सा लग सकता है और सभी उपयोग मामलों के लिए सबसे आसान समाधान नहीं हो सकता है, लेकिन यह निश्चित रूप से चीजों को करने का सबसे मजबूत तरीका है।

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

Comments

मुझे लगता है कि यह वास्तव में केवल विशुद्ध रूप से सीएमएस / प्रकाशन स्थितियों में उपयोगी / व्यावहारिक होगा जहां आप डेटा को संसाधित करने के बजाय सामग्री को आगे बढ़ा रहे हैं।

— UpTheCreek

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

— नीर लेवी

Answer 9

यह बहुत हद तक इस बात पर निर्भर करता है कि आप किस तरह के डेटा की रक्षा करना चाहते हैं (कानूनी आवश्यकताओं और ऐसे)।

• सुझावों का एक बहुत प्रमाणीकरण के बारे में है .. मुझे लगता है कि आपको OpenId / Facebook प्रमाणीकरण का उपयोग लॉगिन के रूप में करना चाहिए। (वे सबसे अधिक संभावना है कि आप प्रमाणीकरण सुरक्षा पर अधिक संसाधन खर्च करेंगे)

• डेटाबेस में अद्यतन मानों के साथ-साथ परिवर्तनों को भी सहेजें। इस तरह से आप उपयोगकर्ता X या दिनांक X और Y के बीच में परिवर्तन कर सकते हैं।

Comments

एक वेब साइट के व्यवस्थापक अनुभाग के लिए फेसबुक प्रमाणीकरण ... आप वास्तव में सोचते हैं कि यह एक अच्छा विचार है? सामान्य उपयोगकर्ताओं के लिए, हाँ ... लेकिन व्यवस्थापक अनुभाग के लिए ? मेरे लिए थोड़ा खतरा महसूस होता है ...

— रिचर्ड जेपी ले गुएन

मुझे यकीन नहीं है। लेकिन मुझे लगता है कि यह साइट केवल ओपनिड प्रमाणीकरण चलाती है। और मुझे नहीं लगता कि फेसबुक प्रमाणीकरण और ओपनिड के बीच कोई बड़ा (सिद्धांत रूप में) अंतर है। लेकिन मैंने किसी भी लाइसेंस समझौते या ऐसे नहीं पढ़ा है।

— कार्ल बर्गक्विस्ट

बहुत बुरा विचार व्यवस्थापक प्रमाणीकरण के लिए ओपनिड, यह भी रोलबैक सबसे अधिक बार असंभव है, और बुरा आदमी आपके सिस्टम के अंदर सभी तैयार है ... क्या रोलबैक?

— अरस्तू

बेझिझक समझाइए कि आपको इसका बुरा क्यों लगता है। ठीक है, अगर व्यवस्थापक के रूप में लॉग ऑन करने पर आपको db और बैकअप की पूरी सुविधा मिलती है, तो सुनिश्चित करें कि रोलबैक करना कठिन है, लेकिन उस स्थिति में आप बहुत तैयार हो गए हैं। मेरा सुझाव cmsisch साइट के लिए लक्षित था।

— कार्ल बर्गक्विस्ट

Answer 10

मैंने किसी को भी व्यवस्थापक पासवर्ड के भंडारण / सत्यापन का उल्लेख नहीं किया। कृपया कृपया कृपया सादे पाठ में पीडब्लू को स्टोर न करें, और अधिमानतः ऐसा कुछ भी नहीं है जो उलटा हो सकता है - एक नमकीन एमडी 5 हैश की तरह कुछ का उपयोग करें ताकि बहुत कम से कम अगर कोई संग्रहीत "पासवर्ड" प्राप्त करने के लिए होता है तो उनके पास नहीं है कुछ भी बहुत उपयोगी है, जब तक कि उनके पास आपकी नमक योजना भी न हो।

Comments

-1 से md5 के लिए। आप पासवर्ड के लिए तेज़ हैश नहीं चाहते हैं, यहां तक ​​कि md5ing के साथ अन्य मुद्दों से भी परे। bcrypt एक बेहतर विकल्प होगा।

— काजकाई

Answer 11

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

शायद आप हमेशा प्रशासन अनुभाग को एक बड़ी निर्देशिका में रख सकते हैं, जैसे

http://domain.com/sub/sub/sub/sub/sub/index.php

लेकिन यह वास्तव में अच्छा नहीं है।

शायद आप मुख पृष्ठ में एक क्वेरी स्ट्रिंग शामिल कर सकते हैं, जैसे:

http://domain.com/index.php?display=true

जब यह होता है, तो उपयोगकर्ता नाम और पासवर्ड फ़ील्ड दिखाई देगा।