Ciąg zaburzający w hasłach - osobny czy wspólny?, md5, sha1, logowanie w sesji czy ciastku Opcje

[WebCM]

Rozważmy system użytkowników w portalu internetowym. Aby utrudnić wydobycie hasła z zaszyfrowanego ciągu znaków, można dodać ciąg zaburzający (sól). Czy gra jest warta świeczki? W końcu atakujący musi uzyskać zakodowane hasło. Generować osobne sole i zapisywać je w tabeli "users" obok hasła czy wystarczy 1 dla wszystkich (zapisany w pliku konfiguracyjnym)?

1 ciąg dla wszystkich
+ brak dodatkowego narzutu danych w tabeli z użytkownikami
+ oddzielony od bazy danych
- jeżeli atakujący pozna ciąg, szybciej pozna inne hasła, mając sumy md5/sha1...

Osobny ciąg dla każdego
+ dodatkowe pole w bazie
+ każdy ma inny ciąg, co utrudnia wydobycie hasła
- jeżeli wycieknie baza, nie ma wielkiej różnicy

1. Jeżeli atakujący pozna ciąg zaburzający, czy to mu ułatwi zdobycie hasła? Ciągiem zaburzającym może być również istniejąca wartość w bazie, np. login, e-mail. Mając sól, może sobie wygenerować własną tablicę tęczową dla danej soli, a czy to mu ułatwi szukanie w gotowych tablicach?

2. Czy użycie 2 funkcji sha1( md5(hasło) + ciąg ) zwiększa ryzyko kolizji? W bazie są już zapisane hasła zakodowane md5(haslo), zapiszemy gdzieś ciąg, natomiast md5(haslo + ciag) musielibyśmy wygenerować dodatkowo dla każdego użytkownika.

3. Jaki powinien być skuteczny ciąg zaburzający? Można uniqid(), własną funkcję ze zbioru wartości <0-z>, dane z bazy (login każdy zna, e-mail też łatwo zdobyć).

Jeżeli użytkownik kliknie Zapamiętaj mnie przy logowaniu, zapisuję zakodowane hasło w ciastku. Tak samo jest w IPB. Największe ryzyko jest na publicznych komputerach, gdzie ktoś zapomni się wylogować, stąd potrzeba hashowania. Przeciętny użytkownik nie zna funkcji "karta prywatna", używa prostych haseł. Inne zagrożenie to podsłuch, ale przecież przy logowaniu podajesz hasło jawne. Nie piszcie o SSL, bo nie wszędzie to wykonalne.

Ten post edytował WebCM 29.07.2012, 00:49:47

[Crozin]

A może hybryda: hasło + kod wspólny + kod osobny?

Tak, to może być dobre rozwiązanie - na pewno nie zaszkodzi.

[...] kto będzie świadomy, że jest zalogowany na publicznym komputerze i skorzysta z deaktywacji?

Sam miałem bodajże dwa razy taką sytuację, gdzie już po fakcie przypomniałem sobie że w kafejce internetowej mogłem zalogować się z opcją zapamiętania. Gdybym serwis w którym się zalogowałem miał możliwość unieważnienia wszystkich zapamiętanych w ciasteczkach logowaniach na pewno bym z tego skorzystał. Szczególnie w sytuacji gdybym z owego serwisu dostał jeszcze maila/informację przy ponownym zalogowaniu, że zalogowano się z innego urządzenia (coraz popularniejszy bajer).

Przejęcie ciasteczka w ataku XSS jest praktycznie niemożliwe po dodaniu flagi http_only.

XSS to nie jedyna opcja na przejęcie ciasteczka. Nie mniej jednak w ciastkach nie powinno pod żadnym pozorem przechowywać się żadnych poufnych danych, które nie są niezbędne. Hasło czy jego hash tylko niepotrzebnie mógłby kusić los. Losowy, nic nie znaczący ciąg znaków powiązany z użytkownikiem w pełni wystarcza tutaj do autoryzacji.

Mając już hasła w bazie w postaci md5(hasło) pozostaje zresetować hasła wszystkim użytkownikom, aby wprowadzić bezpieczniejszy sposób ich przechowywania. O ile to w ogóle istotne, bo przecież nie piszę skryptu dla Pentagonu, CBŚ.

Niekoniecznie. Mail z informacją o tym, że hasło zostało zresetowane przez administrację zawsze budzi ogromny niepokój wśród użytkowników. Możesz przechowywać w bazie danych informację o algorytmie hashowania (md5/bcrypt - czy co tam będzie). Przy logowaniu się użytkownika sprawdzasz czy jego hasło jest w MD5, jeżeli tak jesteś wstanie wygenerować nowy hash hasła. Ewentualnie po jakimś czasie możesz nieaktywnym użytkownikom wysłać maila z informacją o tym, że dobrą praktyką jest okresowe zmienianie hasła.