Squid पासवर्ड और आठ-वर्ण की DES crypt सीमा
Squid को दोष देने या असंगत पासवर्ड फ़ाइल चुपचाप फिर से बनाने से पहले दिखने वाली पासवर्ड-कटौती को संग्रहीत hash फ़ॉर्मैट तक पहुँचाइए।
प्रॉक्सी पुराना पासवर्ड तब स्वीकार करता है जब उसका अंत बदल जाता है, या पासवर्ड फ़ाइल का स्थानांतरण अचानक लंबे पासवर्ड वाले खातों को तोड़ देता है। सबके पासवर्ड छोटे करने से पहले hash फ़ॉर्मैट की जाँच करें।
Apache का htpasswd -d पुराना crypt() हैशिंग चुनता है। उसकी प्रलेखित DES सीमा आठ महत्वपूर्ण पासवर्ड वर्ण हैं। यह सीमा फ़ॉर्मैट की है, Squid में पासवर्ड के लिए किसी सार्वभौमिक आठ-वर्ण नियम की नहीं।
NCSA सहायक संग्रहीत पासवर्ड निरूपण पढ़ता है और दिया गया मान उन फ़ॉर्मैट में जाँचता है जिन्हें वह सहायक और उसका प्लेटफ़ॉर्म समर्थित करते हैं। किसी फ़ाइल को “htpasswd फ़ॉर्मैट” कहना यह निश्चित नहीं करता कि हर ऐतिहासिक और वर्तमान सहायक htpasswd के हर विकल्प द्वारा बनाए गए हर hash एल्गोरिद्म को स्वीकार करता है।
निरूपण का स्थानांतरण सोच-समझकर करें
सुरक्षित बैकअप रखें और मौजूदा प्रविष्टियों का प्रयुक्त फ़ॉर्मैट पहचानें। प्रतिस्थापन एल्गोरिद्म चुनने से पहले संस्थापित सहायक का मैनुअल और डिस्ट्रिब्यूशन बिल्ड देखें।
फिर छोटे स्वीकृत परीक्षण खाते को उसी सहायक और उसी प्रॉक्सी पथ से सत्यापित करें जो वास्तविक खाते उपयोग करते हैं। जनरेटर का फ़ाइल सफलतापूर्वक लिखना यह सिद्ध नहीं करता कि उपभोक्ता सहायक उसे मान्य कर सकता है। ऐसा परीक्षण पासवर्ड लें जिसके महत्वपूर्ण वर्ण पुरानी सीमा से आगे जाते हों।
फ़ॉर्मैट बदलने के लिए सामान्यतः वास्तविक पासवर्ड या पासवर्ड रीसेट चाहिए। पुराने hash को पूरे मूल पासवर्ड के मज़बूत hash में नहीं बदला जा सकता यदि वह जानकारी कभी संरक्षित नहीं की गई।
अंत में, स्थानांतरण की विफलता को कैश किए गए प्रमाणीकरण से अलग पहचानें। पहले से प्रमाणित क्लाइंट कुछ समय तक काम करता रह सकता है भले ही नया सत्यापन विफल हो। नए प्रमाणीकरण और मौजूदा सत्रों दोनों को ध्यान में रखते हुए रोलआउट की योजना बनाएँ।
बग रिपोर्ट में पासवर्ड फ़ाइल प्रकाशित न करें। एल्गोरिद्म मार्कर और कृत्रिम खाता सामान्यतः वास्तविक उपयोगकर्ताओं के hash से अधिक उपयोगी प्रमाण देते हैं।