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]

Wyciek kodów to szybkiej autoryzacji to już rzeczywiście pewien problem. Cały szkopuł tkwi w tym, że owy losowy ciąg znaków zapisany w bazie danych i w ciastku użytkownika jest wszystkim co stanowi podstawę do założenia, że żądanie z danej przeglądarki zostało wykonane przez użytkownika o id x. Wszystkie inne dane są tutaj nie istotne, bo albo są banalnie proste do sfałszowania, albo zmieniają się zbyt często, co w efekcie prowadzi do wylogowania zapamiętanego użytkownika.

W sumie z tego można by stworzyć nowy wątek. W jaki sposób przechowywać te kody by w razie ich wycieku użytkownicy nadal pozostawali bezpieczni - jak w przypadku wycieku normalnych haseł.

Co można zrobić by przynajmniej zmniejszyć prawdopodobieństwo wycieku tych danych? Można je wywalić z bazy danych i przenieść bezpośrednio do pamięci serwera. Jednak tutaj potrzebujemy albo niezwykle stabilnej maszyny, działającej nieprzerwanie całymi miesiącami, albo infrastrukturą w której awaria jednej maszyny nie prowadzi do wyłączenia aplikacji.
Co można zrobić by zminimalizować starty w przypadku gdy nieautoryzowana osoba ma dostęp do tych danych? Użytkownikom, którzy zalogowali się poprzez ciasteczko, a nie normalny formularz logowania, nadać mniejsze uprawnienia, a przy wejściu na wrażliwe podstrony wymagać od nich podania hasła. Czyli na przykładzie tego forum, po zalogowaniu przez ciasteczko mógłbym pisać posty czy prywatne wiadomości, ale musiałbym dokonać pełnej autoryzacji chcąc wejść w ustawienia konta.