Squid પાસવર્ડ અને આઠ-અક્ષરની DES crypt મર્યાદા

પ્રોક્સી જૂનો પાસવર્ડ ત્યારે સ્વીકારે છે જ્યારે તેનો અંત બદલાય, અથવા પાસવર્ડ ફાઇલ સ્થળાંતર અચાનક લાંબા પાસવર્ડવાળા ખાતાં તોડી નાખે છે. બધાના પાસવર્ડ ટૂંકા કરતાં પહેલાં hash ફોર્મેટ તપાસો.

Apache નું htpasswd -d જૂનું crypt() હેશિંગ પસંદ કરે છે. તેની દસ્તાવેજીકૃત DES મર્યાદા આઠ અર્થપૂર્ણ પાસવર્ડ અક્ષરો છે. એ મર્યાદા ફોર્મેટની છે, Squid માં પાસવર્ડ માટેની સાર્વત્રિક આઠ-અક્ષરની નિયમની નથી.

NCSA સહાયક સંગ્રહિત પાસવર્ડ રજૂઆત વાંચે છે અને આપેલ મૂલ્યને એ સહાયક તથા તેના પ્લેટફોર્મ દ્વારા સમર્થિત ફોર્મેટમાં ચકાસે છે. ફાઇલને “htpasswd ફોર્મેટ” કહેવું એ બાંયધરી આપતું નથી કે દરેક ઐતિહાસિક અને વર્તમાન સહાયક htpasswd ના દરેક વિકલ્પે ઉત્પન્ન કરેલ દરેક hash અલ્ગોરિધમ સ્વીકારે છે.

રજૂઆતનું સ્થળાંતર સભાનપણે કરો

સુરક્ષિત બેકઅપ રાખો અને હાલની એન્ટ્રીઓ વાપરતું ફોર્મેટ ઓળખો. બદલીનું અલ્ગોરિધમ પસંદ કરતાં પહેલાં સ્થાપિત સહાયકનું મેન્યુઅલ અને ડિસ્ટ્રિબ્યુશન બિલ્ડ તપાસો.

પછી નાનું મંજૂર પરીક્ષણ ખાતું એ જ સહાયક અને એ જ પ્રોક્સી માર્ગેથી ચકાસો જે વાસ્તવિક ખાતાં વાપરે છે. જનરેટર ફાઇલ સફળતાપૂર્વક લખે એ સાબિત કરતું નથી કે વાપરનાર સહાયક તેને માન્ય ઠેરવી શકે. એવો પરીક્ષણ પાસવર્ડ વાપરો જેના અર્થપૂર્ણ અક્ષરો જૂની મર્યાદાથી આગળ જાય.

ફોર્મેટ બદલવા સામાન્ય રીતે વાસ્તવિક પાસવર્ડ કે પાસવર્ડ રીસેટ જરૂરી છે. જૂનો hash સંપૂર્ણ મૂળ પાસવર્ડના વધુ મજબૂત hash માં ફેરવી શકાતો નથી જો એ માહિતી કદી સાચવવામાં આવી ન હોય.

છેલ્લે, સ્થળાંતર નિષ્ફળતાને કેશ કરેલી પ્રમાણીકરણથી અલગ પાડો. પહેલેથી પ્રમાણિત ક્લાયન્ટ નવી ચકાસણી નિષ્ફળ જાય તો પણ થોડો સમય કામ ચાલુ રાખી શકે છે. નવા પ્રમાણીકરણ અને હાલના સત્રો બંને ધ્યાનમાં રાખીને રોલઆઉટ યોજો.

બગ રિપોર્ટમાં પાસવર્ડ ફાઇલ પ્રકાશિત કરશો નહીં. અલ્ગોરિધમ માર્કર અને કૃત્રિમ ખાતું સામાન્ય રીતે વાસ્તવિક વપરાશકર્તાઓના hash કરતાં વધુ ઉપયોગી પુરાવા આપે છે.