यह किस स्तर की सुरक्षा प्रदान करता है?
.htpasswd स्वयं से अधिक सुरक्षा प्रदान नहीं करता है। यही है, यह एक लॉगिन तंत्र प्रदान करता है, और अपाचे उचित क्रेडेंशियल्स के बिना प्रतिक्रिया नहीं देगा, लेकिन अलग-अलग कॉन्फ़िगर किए जाने तक, एक्सचेंज के बारे में कुछ भी एन्क्रिप्ट नहीं किया जाता है (या यहां तक कि obfuscated)। उदाहरण के लिए, Wireshark साथ GET अनुरोध को सुनने के लिए आप सभी हेडर का एक अच्छा दृश्य ग्राहक द्वारा भेजा जा रहा है, जिनमें शामिल हैं:
Authorization: Basic d3BhbG1lcjp0ZXN0dGVzdA==
"d3BhbG1lcjp0ZXN0dGVzdA==" बस base64 जा रहा है इनकोडिंग "wpalmer:testtest" के रूप। इन दिनों, एक हैकर (या अधिक संभावना है, एक वायरस) सार्वजनिक वाईफाई कनेक्शन पर बैठ सकता है और बाद में किसी भी अनुरोध के लिए Authorization: वाले किसी भी अनुरोध को लॉग कर सकता है। सामान्य रूप से, एक अनएन्क्रिप्टेड HTTP कनेक्शन पर किसी भी प्रमाणीकरण जानकारी को एक बुरा विचार माना जाता है, भले ही आप एक तार से अधिक हों या सुरक्षित वाईफाई अंत-टू-एंड। उदाहरण के लिए, लॉक के पीछे आप ग्राहक डेटा, भुगतान जानकारी आदि संग्रहीत कर रहे थे, उदाहरण के लिए, PCI Compliance की आवश्यकताओं को पूरा नहीं करेंगे।
मिश्रण करने के लिए https जोड़ें, और आप पूरी तरह से है कि विशेष समस्या को खत्म करने, फिर भी ...
.htpasswd प्रमाणीकरण के रूप में अपाचे httpd द्वारा कार्यान्वित दर सीमित या जानवर बल की सुरक्षा के किसी भी रूप प्रदान नहीं करता है। आप पासवर्ड अनुमान पर कई एक साथ प्रयास कर सकते हैं क्योंकि अपाचे एक साथ पृष्ठों की सेवा करने के इच्छुक है, और अपाचे सफलतापूर्वक/विफलता के साथ प्रतिक्रिया दे सकता है जितनी जल्दी हो सके। क्लाइंट को सर्वर से बात करने से अवरुद्ध होने से पहले असफल प्रयासों की संख्या सीमित करने के लिए आप Fail2Ban जैसे कुछ का उपयोग कर सकते हैं, लेकिन यह आवश्यक नहीं होगा कि एक बोनेट के खिलाफ कोई उपयोगी सुरक्षा प्रदान करे, जो स्वचालित रूप से आपके सर्वर को हजारों अद्वितीय से लक्षित कर सकता है पतों। इससे का निर्णय हो सकता है "क्या मैं खुद को बोनेट से पासवर्ड प्रयासों के लिए कमजोर छोड़ देता हूं, या क्या मैं खुद को अस्वीकार करने के लिए कमजोर छोड़ देता हूं, जब पूरे खाते को कई ग्राहकों से विफलताओं के कारण बंद कर दिया जाता है?"
हमले के इन कोणों को आपके .htaccess फ़ाइल पर आईपी-आधारित प्रतिबंध जोड़कर सीमित किया जा सकता है, केवल कुछ पते से कनेक्शन की अनुमति देता है। आप कैसे काम करते हैं इस पर निर्भर करते हुए, यह असुविधाजनक हो सकता है, लेकिन यह उन खतरों के प्रकारों को भी गंभीर रूप से सीमित करता है जिनके लिए आप कमजोर होंगे। आपको अभी भी आपकी साइट को लक्षित करने वाले किसी व्यक्ति या नेटवर्क आधारभूत संरचना के हिस्से में संक्रमण से जोखिम होगा। जिस सामग्री की आप रक्षा कर रहे हैं उसके आधार पर, यह "पर्याप्त पर्याप्त" हो सकता है।इस प्रकार के प्रतिबंध का एक उदाहरण है:
Order deny,allow
Deny from all
Allow from 127.0.0.1
इसका मतलब है, संक्षेप में, "केवल स्थानीय होस्ट से कनेक्शन की अनुमति दें"। लाइन-दर-पंक्ति, इसका मतलब है:
Order deny,allow जिस क्रम में नियम आखिरी मैच पूर्वता लेने के साथ कार्रवाई की जाती है, को परिभाषित करता है।Deny from all यह सोचते हैं कि सभी ग्राहकोंAllow from 127.0.0.1 अगर ग्राहक आईपी 127.0.0.1 है वंचित रखा जाता है द्वारा शुरू करते हैं, तो यह
अनुमति दी है कुछ हद तक, आईपी आधारित प्रतिबंध भी बिंदु है जहां के लिए आप की रक्षा करेगा एचटीटीपीएस वैकल्पिक माना जा सकता है। हमलावर/वायरस अभी भी आपके क्रेडेंशियल्स देख सकते हैं, लेकिन उनके लिए पृष्ठ पर उन प्रमाण-पत्रों का उपयोग करना कठिन होता है। दोबारा, यह पीसीआई अनुपालन नहीं होगा, और यह "महत्वपूर्ण" जानकारी के लिए उपयुक्त नहीं होगा, लेकिन कुछ स्थितियां हैं जिनके लिए इसे "पर्याप्त पर्याप्त" माना जा सकता है। सावधान रहें कि कई लोग कई साइटों पर क्रेडेंशियल्स का पुन: उपयोग करते हैं, इसलिए लॉगिन विवरणों की रक्षा करने में असफलता को आम तौर पर उपयोगकर्ता के लिए बहुत खतरनाक माना जाता है, भले ही साइट स्वयं सुरक्षित है।
अंत में, .htaccess फ़ाइल स्वयं ही देयता का एक सा है। "क्या उन्हें सार्वजनिक निर्देशिका के बाहर होने की आवश्यकता है?" के जवाब देखें उस पर अधिक जानकारी के लिए।
क्या इसे आसानी से बाईपास किया जा सकता है?
नहीं। सर्वर से, जब उचित रूप से कॉन्फ़िगर किया गया है, तो यह सुनिश्चित करने का कोई कारण नहीं है कि सुरक्षित सामग्री तक पहुंचने के लिए कभी भी लॉगिन विवरण की आवश्यकता नहीं होगी। जबकि HTTP बेसिक प्रमाणीकरण में इसकी त्रुटियां हैं, अपाचे httpd बहुत मजबूत है और दुनिया में सॉफ़्टवेयर के सबसे अच्छी तरह से परीक्षण किए गए टुकड़ों में से एक है। यदि आप अपाचे को बताते हैं कि कुछ सामग्री तक पहुंचने के लिए HTTP मूल प्रमाणीकरण की आवश्यकता है, तो इसकी आवश्यकता होगी।
यदि डिफ़ॉल्ट रूप से अपाचे उपयोगकर्ताओं को दो फ़ाइलों में से किसी एक को सीधे एक्सेस करने की अनुमति नहीं देता है, तो क्या उन्हें सार्वजनिक निर्देशिका के बाहर होने की आवश्यकता है?
इसमें कुछ बिंदु हैं। सबसे पहले, अपाचे इन फ़ाइलों में से किसी एक तक पहुंच को रोकने के लिए डिफ़ॉल्ट नहीं है। अपाचे httpd के कई वितरण में प्रारंभिक कॉन्फ़िगरेशन शामिल है जो वितरण, .htaccess/.htpasswd फ़ाइलों, .ht* फ़ाइलों, या .* फ़ाइलों के आधार पर पहुंच को रोकता है ("सभी से अस्वीकार करें" नियमों का उपयोग करके)। यह बहुत आम है, लेकिन कई कारण हैं कि यह मामला क्यों नहीं हो सकता है। तुम्हें पता है, इन फ़ाइलों को ब्लॉक करने के लिए एक नियम अपने आप को जोड़ सकते हैं अगर वे पहले से अवरोधित नहीं हैं:
<FilesMatch "^.(htaccess|htpasswd)$">
Order Allow,Deny
Deny from all
</FilesMatch>
दूसरे, यह बताया जाना चाहिए कि जिस तरह से .htaccess फ़ाइलें काम करते हैं, वे कार्रवाई की जाती है जब निर्देशिका वे में मिलान किया जाता है कर रहे हैं । यह कहना है: .htpasswd कहीं और हो सकता है, लेकिन .htaccess एक ही निर्देशिका में होना चाहिए। उस ने कहा, थोड़ा और विस्तार के लिए "गति प्रभाव" खंड देखें।
इसलिए, क्योंकि उन्हें इतनी आसानी से अवरुद्ध किया जा सकता है, सार्वजनिक निर्देशिका के बाहर .htpasswd क्यों रखें? क्योंकि गलतियां होती हैं, और .htpasswd फ़ाइल एक बड़ी देयता है। यहां तक कि यदि आप HTTPS का उपयोग कर रहे हैं, तो आपके .htpasswd फ़ाइल का एक्सपोजर का अर्थ है कि आपके पासवर्ड को ब्रूट-फोर्स अटैक के माध्यम से आसानी से क्रैक किया जा सकता है।इन दिनों, उपभोक्ता-ग्रेड जीपीयू प्रति सेकंड लाखों पासवर्ड अनुमान लगा सकते हैं। इससे तुलनात्मक रूप से कम समय में "मजबूत" पासवर्ड भी गिर सकते हैं। दोबारा, यह तर्क आम तौर पर केवल लक्षित हमले पर लागू होता है, लेकिन तथ्य यह है कि यदि किसी हमलावर के पास आपकी .htpasswd फ़ाइल है और आपके सिस्टम तक पहुंच चाहता है, तो इन दिनों, वे आसानी से ऐसा करने में सक्षम हो सकते हैं। चीजों की स्थिति के अपेक्षाकृत हालिया (अप्रैल 2012) के अवलोकन के लिए कोडिंग डरावनी पर Speed Hashing देखें।
इस बात को ध्यान में रखते हुए, .htaccess फ़ाइल को उजागर करने के लिए गलती से (अस्थायी रूप से) की संभावना कहीं भी इसे स्थानांतरित करने लायक है, जिसे कभी भी httpd की सेवा करने के लिए सामग्री की तलाश में नहीं देखा जाना चाहिए। हां, अभी भी कॉन्फ़िगरेशन परिवर्तन हैं जो इसे "सार्वजनिक निर्देशिका में" के बजाय "एक स्तर ऊपर" होने पर इसका पर्दाफाश कर सकते हैं, लेकिन उन परिवर्तनों को गलती से होने की संभावना बहुत कम है।
क्या कोई गति प्रभाव है?
कुछ।
सबसे पहले, .htaccess फ़ाइलों का उपयोग कुछ हद तक धीमा करता है। अधिक विशेष रूप से, AllowOverride all निर्देश बहुत संभावित धीमी गति का कारण बनता है। इससे अपाचे को प्रत्येक निर्देशिका में .htaccess फ़ाइलों और निर्देशिका के प्रत्येक अभिभावक को देखने का कारण बनता है, जिसे एक्सेस किया जाता है (DocumentRoot तक) और इसमें शामिल है। इसका मतलब है प्रत्येक अनुरोध के लिए फ़ाइल (या फ़ाइल के अपडेट) के लिए फाइल सिस्टम से पूछताछ करना। संभावित रूप से के विकल्प की तुलना में फाइल सिस्टम को मारने से, यह काफी अंतर है।
तो, .htaccess क्यों मौजूद है? ऐसे कई कारण हैं जो इसे "इसके लायक" बना सकते हैं:
- आपके सर्वर लोड के आधार पर, आप कभी अंतर नहीं देख सकते हैं। क्या आपके सर्वर को हर अनुरोध के बाहर हर अंतिम मिलीसेकंद को निचोड़ने की ज़रूरत है? यदि नहीं, तो इसके बारे में चिंता न करें। हमेशा की तरह, अनुमानों और अनुमानों के बारे में चिंता न करें। अपनी वास्तविक दुनिया की स्थितियों को प्रोफाइल करें और देखें कि इससे कोई फर्क पड़ता है या नहीं।
.htaccess सर्वर को पुनरारंभ किए बिना संशोधित किया जा सकता है। वास्तव में, यह इतना धीमा बनाता है- अपाचे जांच के लिए जांच करता है या प्रत्येक अनुरोध पर .htaccess फ़ाइल की उपस्थिति, इसलिए परिवर्तन तुरंत लागू होते हैं।.htaccess में एक त्रुटि निर्देशिका को ले जाएगा, न कि सर्वर पर। यह httpd.conf फ़ाइल को बदलने से ज़िम्मेदारी से बहुत कम बनाता है।.htaccess संशोधित किया जा सकता है भले ही आपके पास केवल एक ही निर्देशिका में लेखन-पहुंच हो। यह साझा होस्टिंग वातावरण के लिए आदर्श बनाता है। httpd.conf पर पहुंचने की कोई आवश्यकता नहीं है, या सर्वर को पुनरारंभ करने के लिए उपयोग की आवश्यकता नहीं है।.htaccess उन फ़ाइलों के बगल में पहुंच के लिए नियम रख सकते हैं जिनका प्रभाव वे हैं। इससे उन्हें ढूंढना बहुत आसान हो सकता है, और केवल चीजों को और व्यवस्थित रखता है।
.htaccess का उपयोग करना चाहते हैं, यहां तक कि उपरोक्त सभी पर विचार भी नहीं करना चाहिए? .htaccess पर लागू होने वाला कोई भी नियम सीधे httpd.conf या एक शामिल फ़ाइल में जोड़ा जा सकता है।
.htpasswd के बारे में क्या? यह इस बात पर निर्भर करता है कि आपके पास कितने उपयोगकर्ता हैं। यह फ़ाइल-आधारित है, और न्यूनतम कार्यान्वयन के मामले में न्यूनतम है।The docs for httpd 2.2 से:
जिस तरह से कि मूल प्रमाणीकरण निर्दिष्ट किया जाता है की
, अपने यूज़रनेम और पासवर्ड हर बार जब आप सर्वर से एक दस्तावेज़ का अनुरोध सत्यापित किया जाना चाहिए। यह तब भी है जब आप उसी पृष्ठ को पुनः लोड कर रहे हैं, और पृष्ठ पर प्रत्येक छवि के लिए (यदि वे संरक्षित निर्देशिका से आते हैं)। जैसा कि आप कल्पना कर सकते हैं, यह चीजों को थोड़ा धीमा कर देता है। जो चीजें धीमा करती है वह पासवर्ड फ़ाइल के आकार के समान होती है, क्योंकि इसे उस फ़ाइल को खोलना होता है, और उपयोगकर्ताओं की सूची तब तक नीचे जा सकता है जब तक कि यह आपके नाम पर न हो जाए। और इसे पृष्ठ 0 लोड होने पर हर ऐसा करना होगा।
इसका एक परिणाम यह है कि उपयोगकर्ताओं के लिए एक व्यावहारिक सीमा है कि आप एक पासवर्ड फ़ाइल में डाल सकते हैं। यह सीमा आपकी विशेष सर्वर मशीन के प्रदर्शन पर के आधार पर अलग-अलग हो जाएगी, लेकिन आप कुछ सौ प्रविष्टियों से ऊपर हो जाने के बाद मंदी देखने की उम्मीद कर सकते हैं, और उस समय एक अलग प्रमाणीकरण विधि पर विचार करना चाह सकता है।
संक्षेप में, .htpasswd धीमा है। यदि आपके पास केवल कुछ हद तक उपयोगकर्ता हैं जिन्हें प्रमाणित करने की आवश्यकता है, तो आप कभी भी ध्यान नहीं देंगे, लेकिन यह अभी तक एक और विचार है।
सारांश
.htpasswd के साथ एक व्यवस्थापक अनुभाग सुरक्षित सभी परिस्थितियों के लिए आदर्श नहीं है। इसकी सादगी को देखते हुए, यह उन जोखिमों और समस्याओं के लायक हो सकता है जहां सुरक्षा और प्रदर्शन प्राथमिकताओं के उच्चतम नहीं हैं। कई स्थितियों के लिए, थोड़ी-थोड़ी tweaking के साथ, इसे "काफी अच्छा" माना जा सकता है। आपके लिए "पर्याप्त पर्याप्त" एक निर्णय कॉल है जो आपके लिए तैयार है।