Hasła Squida i limit ośmiu znaków DES crypt
Prześledź pozorne obcięcie hasła do formatu zapisanego skrótu, zanim obwinisz Squida lub po cichu odtworzysz niezgodny plik haseł.
Serwer proxy akceptuje stare hasło, gdy zmienia się jego końcówka, albo migracja pliku haseł nagle psuje konta z długimi hasłami. Sprawdź format skrótu, zanim skrócisz wszystkim hasła.
htpasswd -d Apache'a wybiera starsze skróty crypt(). Udokumentowane ograniczenie DES to osiem znaczących znaków hasła. To ograniczenie należy do formatu, a nie do uniwersalnej zasady ośmiu znaków dla haseł w Squidzie.
Pomocnik NCSA odczytuje zapisaną reprezentację hasła i weryfikuje podaną wartość w formatach obsługiwanych przez ten pomocnik i jego platformę. Nazwanie pliku “formatem htpasswd” nie gwarantuje, że każdy historyczny i obecny pomocnik akceptuje każdy algorytm skrótu wytwarzany przez każdą opcję htpasswd.
Migruj reprezentację świadomie
Zachowaj chronioną kopię zapasową i ustal format używany przez istniejące wpisy. Sprawdź podręcznik zainstalowanego pomocnika i build dystrybucji przed wyborem algorytmu zastępczego.
Następnie zweryfikuj małe zatwierdzone konto testowe tą samą ścieżką pomocnika i proxy, której używają prawdziwe konta. To, że generator pomyślnie zapisze plik, nie dowodzi, że czytający go pomocnik potrafi go zweryfikować. Użyj hasła testowego, którego znaczące znaki wykraczają poza starą granicę.
Zmiana formatu wymaga zwykle rzeczywistego hasła lub resetu hasła. Starego skrótu nie da się przekształcić w silniejszy skrót pełnego oryginalnego hasła, jeśli ta informacja nigdy nie została zachowana.
Na koniec odróżnij niepowodzenie migracji od uwierzytelnienia z pamięci podręcznej. Już uwierzytelniony klient może przez jakiś czas działać dalej, nawet gdy nowa weryfikacja by się nie powiodła. Zaplanuj wdrożenie zarówno wokół świeżego uwierzytelnienia, jak i istniejących sesji.
Nie publikuj pliku haseł w zgłoszeniu błędu. Znacznik algorytmu i konto syntetyczne zwykle dają użyteczniejsze dowody niż skróty prawdziwych użytkowników.