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]

greycoffey: Chodzi mi o zastosowanie 2 różnych funkcji, kiedy w bazie mam md5(hasło), a nie mam md5(hasło+kod). Mając w ciastku hash(md5(hasło) + kod) po prostu sprawdzamy, czy zgadza się z tym, co jest w bazie. Czy to poważnie zwiększa ryzyko kolizji?

Doszedłem do kilku wniosków:

1. Jeśli mamy chronić hasła na wypadek wycieku bazy danych, hasła i tak muszą być zapisane w postaci szyfr(hasło + kod). Najczęstszą przyczyną wycieków są niezabezpieczone zrzuty tabel na serwerze z plikami serwisu.

2. Kod powinien być ściśle tajny. Wtedy atakujący nie wygeneruje sobie tablic tęczowych dla danego kodu, bo go nie zna!

3. Czy 1 kod dla wszystkich jest mniej bezpieczny? Jeżeli atakujący uzyska dostęp do plików konfiguracyjnych, wtedy mamy problem. Zdarzają się takie wpadki na serwerach. Jeśli zapiszemy osobne kody dla każdego w bazie, atakujący ma podane wszystkie kody - nic, tylko generować tablice!

4. W sytuacji, gdy w bazie są już md5(hasło) i chcemy zmienić na szyfr(hasło + kod), jedynym wyjściem jest reset wszystkich haseł, bo tablice tęczowe nie zwrócą nam wszystkich haseł i jest ryzyko trafienia na kolizję.

5. Większym zagrożeniem jest odczytanie ciastka, przejęcie sesji lub wykorzystanie błędów w aplikacji. Czasami bardziej opłacalny jest atak siłowy niż próba zdobycia bazy danych.

Na początku chciałem tylko zabezpieczyć ciastka. Wszak można je zostawić podczas logowania w miejscach publicznych. A może warto też zabezpieczyć hasła w bazie, czyli szyfr(hasło+kod)?

Przy implementowaniu "Zapamiętaj mnie" pod żadnym warunkiem nie powinieneś wrzucać hasła do ciasteczka (nawet w formie hashu). Wygeneruj unikalny, losowy ciąg, który będzie powiązany z danym użytkownikiem i przeglądarką. Dodatkowo przy każdy poprawnym zalogowaniu przy jego pomocy regeneruj go.

Przynajmniej system nie musi się martwić o zarządzanie sesjami typu "zapamiętaj mnie". Większa odpowiedzialność spada na użytkownika, który używa tej opcji.

[greycoffey]

greycoffey: Chodzi mi o zastosowanie 2 różnych funkcji, kiedy w bazie mam md5(hasło), a nie mam md5(hasło+kod). Mając w ciastku hash(md5(hasło) + kod) po prostu sprawdzamy, czy zgadza się z tym, co jest w bazie. Czy to poważnie zwiększa ryzyko kolizji?

Użycie dwóch różnych funkcji hashujących również zwiększa prawdopodobieństwo kolizji. Mamy dwie funkcje hashujące H i H2, salt S, wiadomości A, B, C i D, więc może zdarzyć się tak:

Kod

H(A)       == H(B)
H2(H(A)+S) == H2(H(B)+S)

H(C)       != H(D)
H2(H(C)+S) == H2(H(D)+S)

Polecam stosowanie wolnych, poprawnych matematycznie funkcji mieszających. MD5, SHA1 nadają się do tworzenia skrótów dużych plików, nie do mieszania haseł, które w porównaniu z wcześniej wymienionymi plikami, są minimialne.