Squid-pasvortoj kaj la ok-signa limo de DES crypt

Prokura servilo akceptas malnovan pasvorton kiam ĝia finaĵo ŝanĝiĝas, aŭ migrado de pasvorta dosiero subite rompas kontojn kun longaj pasvortoj. Kontrolu la haŝan formaton antaŭ ol mallongigi la pasvortojn de ĉiuj.

htpasswd -d de Apache elektas la malnovan haŝadon crypt(). Ĝia dokumentita limo de DES estas ok signifaj signoj de pasvorto. Tiu limo apartenas al la formato, ne al universala regulo de ok signoj por pasvortoj en Squid.

La helpilo NCSA legas la konservitan prezenton de la pasvorto kaj kontrolas la donitan valoron per la formatoj subtenataj de tiu helpilo kaj ĝia platformo. Nomi dosieron “htpasswd-formato” ne garantias, ke ĉiu historia kaj nuna helpilo akceptas ĉiun haŝan algoritmon produktitan de ĉiu opcio htpasswd.

Migru la prezenton intence

Konservu protektitan sekurkopion kaj identigu la formaton uzatan de ekzistantaj eroj. Kontrolu la manlibron de la instalita helpilo kaj la konstruon de la distribuo antaŭ ol elekti la anstataŭan algoritmon.

Poste kontrolu malgrandan aprobitan testan konton per la sama helpilo kaj la sama prokura vojo, kiun uzas la realaj kontoj. Tio, ke generatoro sukcese skribas dosieron, ne pruvas, ke la konsumanta helpilo povas validigi ĝin. Uzu testan pasvorton, kies signifaj signoj etendiĝas preter la malnova limo.

Ŝanĝi formatojn kutime postulas la realan pasvorton aŭ pasvortan restarigon. Malnova haŝo ne transformeblas en pli fortan haŝon de la kompleta originala pasvorto se tiu informo neniam konserviĝis.

Fine, distingi migran malsukceson disde kaŝmemora aŭtentikigo. Jam aŭtentikigita kliento povas daŭre funkcii dum iom da tempo eĉ kiam nova validigo malsukcesus. Planu la lanĉon kaj ĉirkaŭ freŝa aŭtentikigo kaj ĉirkaŭ ekzistantaj sesioj.

Ne publikigu la pasvortan dosieron en cimraporto. La algoritma markilo kaj sinteza konto kutime donas pli utilajn pruvojn ol la haŝoj de realaj uzantoj.