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

[WebCM]

Powiadasz, że znajdzie sobie takie b, że bcrypt(a+sól) = bcrypt(b+sól) nie znając soli. Ale po co ma to liczyć? Jeśli celem jest dostęp, wystarczy mu już samo ciasteczko. Musielibyśmy zastosować dodatkowe zabezpieczenia. To samo dotyczy przechowywania ID sesji. Takie ciastko też łatwo przechwycić. Możemy sprawdzać IP lub... jakiś pomysł?

czasem nawet, żeby wykonać nie autoryzowaną akcje nie trzeba kombinować z logowaniem, user wykona coś za nas nawet nie będąc tego świadomym...

To już jest CSRF, czyli inny temat.

Baza jest o wiele lepiej zabezpieczona niż ciacho

Zgadza się, ale jeśli baza wycieknie, to są większe kłopoty. Rozważamy 2 aspekty: bezpieczeństwo hasła i sesji.

Nadal stoję na stanowisku, że z ciastka postaci ID+hash(hasło+sól) złodziej nie odzyska hasła bez jawnej soli. Może go użyć do zalogowania, co stanowi problem także w przypadku przechowywania ID sesji. Jeśli uzyska dostęp do bazy, to bez różnicy, czy ma ciastko, czy nie. Jakich zabezpieczeń użyć, aby utrudnić przenoszenie ciastek, cokolwiek zawierają?

PS. Teoretycznie hasło da się zdobyć, ale jak długo trzeba liczyć bez jawnej soli?

PS 2. Odnośnie postu poniżej. Mam wątpliwości, że znalezienie kolizji coś mu da. W ciastku trzymamy hash(a+sól), w bazie sól+hash(a+sól). Celem jest znalezienie takiego b, aby:

hash( a + sól ) = hash( b )

1. Jakie jest prawdopodobieństwo, że a+sól = b?
2. Jakie jest prawdopodobieństwo, że za pomocą b zalogujemy się do innych usług?

Ten post edytował WebCM 13.02.2016, 23:31:40