Sól, salt czy jakkolwiek to nazwać a o czym w poprzednim poście pisałem jest stałym dodatkiem do niejawnej wersji hasła czy co tam byś chciał kodować.
Są to ciągi znaków, które się dokleja do danej usera czy to na początek, koniec lub z obu stron i dopiero przeprowadza hashowanie. W ten sposób nawet słabe hasła można uczynić mocnymi. Sprawia to także, że znając czyjeś hasło i znając funkcje jakiej użyto nie wygenerujesz tego samego hasha. A znając hash i nawet gdybyś go rozgryzł do postaci jawnej, to nie wiesz która część w ciągu znaków jest prawidłowym hasłem usera. Tyle że sha-1, md5 i wiele innych jest algorytmami szyfrującymi jednostronnymi. A więc możesz zaszyfrować, ale nie ma funkcji deszyfrującej do nich. Ważne by sól była stała, bo inaczej hashe nie będą się zgadzały. Dlatego daje się do nich kombinacje liter małych i dużych, znaków by utrudnić "złamanie" hashy przez "tęczowe tabliczki"
Ze zmiennymi sesji... mae culpa... nie interesowałem się nigdy zbytnio czy są po stronie serwera czy klienta. I tak zazwyczaj mialem wszystkie krytyczne dane w hashach
Co do sprawdzania to aż tak rygorystycznie nie trzeba, ale co jakiś czas można
Gdy zaś wspominałem o przechowywaniu w sesji loginu i hasła miałem na myśli sytuację, gdy akurat login nie musi być polem jednoznacznie identyfikującym. Tak naprawdę unikatowa jest kombinacja loginu i hasła i dopiero taki warunek trzeba sprawdzać pod kątem kolizyjności w bazie. Może być wielu userów o tym samym loginie ale różnych hasłach. Jedynie z wygody ustawia się na to pole wartość unique by sobie mniej roboty robić i nie wprowadzać zamieszania dla pozostałych użytkowników :] Czyli dla wygody nas, adminów, tak naprawdę, a nie dlatego, że tak musi być
Oszczędza nam to dodatkowego sprawdzenia hasła i tyle
Zmiana loginu, nawet na już istniejący, po założeniu konta w takim wypadku to pikuś i użytkownik sam to może zrobić, jedynie trzeba sprawdzać unikatowość kombinacji w formularzu zmiany loginu.
)