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]

Jeśli dajesz komuś na tacy hasło to poco mu baza

Nie daję hasła na tacy, co już zostało powiedziane.

Zaraz, czy ja dobrze rozumiem: chcesz w ciastku umieszczać hash, ale bez soli?

Tak. Akurat sól w bcrypt ma 22 znaki bez 2 bitów. Różnica dla atakującego jest taka, że nie zna soli, więc odnalezienie hasła jest wyjątkowo trudne. Nawet jeśli znajdzie kolizję, niewiele na tym zyska.

Ad. 1. Wystarczy ID sesji, całość obsługi sesji po stronie serwera. Żadnych haseł, hashy haseł - bo i po co?

W przypadku logowania bez opcji "zapamiętaj mnie" wystarczy odpowiednio zabezpieczona sesja PHP. Oczywiście w systemach krytycznych są potrzebne dodatkowe środki bezpieczeństwa, ale na zwykłych portalach to wystarczy.

Ad. 2. W przypadku autologowania wystarczy token, tabela w bazie, która przechowuje token, id użytkownika datę utworzenia/ważności i dane identyfikujące (User Agent, IP, Host, Browser Fingerprint etc).

Jak prawidłowo zabezpieczyć system przed skopiowaniem ciastka? Możemy sprawdzać IP i User-Agent, tylko czy to nie utrudni życia osobom ze zmiennym IP? A jak adres IP jest ten sam i proxy nie przekazuje adresu wewnętrznego?

No to załóżmy ten bezpieczniejszy wariant, że tworzymy tabelę sessions i tam przechowujemy logowania typu "zapamiętaj mnie". Jak wycieknie baza, złodziej utworzy ciastko z danymi w tabeli "sessions" i zostanie zalogowany. Można ochronić się przed tym, szyfrując jednostronnie żeton (token). Jaki algorytm? bcrypt? Czy nie obciążymy serwera, licząc bcrypt przy każdym żądaniu? A gdy wycieknie ciastko z żetonem, musimy zastosować inne mechanizmy, np. badać IP, User Agent, ale jednocześnie możemy utrudnić życie osobom ze zmiennym IP. UA zmieni się po aktualizacji przeglądarki, zatem jakie dane zapisywać?