Forum PHP.pl

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

Było już o tym wiele razy.
Unikalna sól dla każdego użytkownika - to praktycznie uniemożliwia wygenerowanie tablicy tęczowej, ponieważ dla każdego pojedynczego użytkownika trzeba by wygenerować nową.

1. Posiadanie soli to pierwszy warunek konieczny w przypadku chęci znalezienia kolizji dla danego hasha.
2. Wielokrotne hashowanie nie ma większego sensu. Coś co jest już wymieszane/"losowe" nie będzie bardziej wymieszane po ponownym pomieszaniu tego.
3. Najlepiej ciąg kilkudziesięciu losowych bajtów.

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.

PS. MD5/SHA1 to funkcje, które nie nadają się do hashowania haseł - powinieneś skorzystać z Blowfisha bądź podobnych algorytmów.

Ten post edytował Crozin 29.07.2012, 01:03:52

Apropo podwójnego hashowania:

Posiadamy funkcję hashującą H(message).
Możemy znaleźć dwie wiadomości A i B, które spełniają następujące równania

Oraz dwie wiadomości C i D, które spełniają te poniższe:

Co wskazuje na to, że n-hashowanie zwiększa szanse na wystąpienie kolizji.

Ten post edytował greycoffey 29.07.2012, 22:18:59

było już wiele razy o tym, że nie ma to żadnego znaczenia czy sól jest unikalna na usera czy na portal:)


wat ? mówiąc blowfish miałeś na myśli rodzinę sha-2 ?

Ten post edytował yevaud 30.07.2012, 09:29:44

Podstawowa cecha unikalnej soli - brak możliwości stworzenia tablicy tęczowej pod daną bazę danych. Także nie wiem gdzie o tym wspomniano "wiele razy".
Dla MD5 znajdziesz kolizję w kilkanaście sekund, to raz. Dwa, że oba są po prostu za szybkie.

Kolizje są mega długie. System autoryzacji odrzuci próbę logowania przy użyciu zbyt długiego hasła.
Problem nie istnieje.

@WebCM
Nie ma potrzeby tworzyć kolejnego pola w bazie.
Wystarczy doczepić sól do hasha i w takiej postaci zapisać do bazy.
Wymagać to będzie nieco więcej logiki, mimo to się opłaca.

Ten post edytował wNogachSpisz 30.07.2012, 10:04:30

Kolizje wcale nie muszą być "mega długie" - przykład.

Przeprowadź zatem skuteczny atak wykorzystujący takie krótkie kolizje.

Ten post edytował wNogachSpisz 30.07.2012, 13:55:18

+1
Co nie znaczy że można to olewać

Muszę małe sprostowanie do swojego postu napisać. Byłem w pełni przekonany, że dla MD5 poza możliwością szybkiego znalezienia kolizji istnieje również możliwość szybkiego zmodyfikowania ciągu by generował odpowiedni hash. Nie mniej jednak, możliwość znalezienia kolizji dyskwalifikuje dany algorytm już na początku - szczególnie gdy mamy równie prosty dostęp do innych algorytmów nie posiadających tej wady.
Jednak najistotniejszym powodem jest wspomniana już przeze mnie szybkość działania MD5/SHA-1/wszystkich funkcji hashujących ogólnego przeznaczenia. Są o kilka rzędów wielkości za szybkie.

PS. Krótki wywód n/t bezpiecznego przechowywania haseł: http://codahale.com/how-to-safely-store-a-password/

Ten post edytował Crozin 30.07.2012, 16:14:58

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)?

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.

chodziło mi o to, że Blowfish to szyfr symetryczny, a nie algorytm hashujący prawdopodobnie chodziło Ci o ten "Blowfish keying schedule" który jest wspomniany w podanym przez Ciebie artykule


watpie, żeby osoba która zadala to pytanie miala tyle milionow userow w bazie żeby to robiło różnicę a jeśli ma to zamiast pytać tutaj powinna zatrudnić specjalistę od zabezpieczeń który jej powie co trzeba zrobić z danymi wrażliwymi i hasłami.
Podsumowując: to nie ma znaczenia. Klótnie na ten temat przewijaja sie w calym necie raz na jakiś czas

kończąc mój przemądrzały wywód wspomnę tylko o podstawowej zasadzie dotyczącej wszelkich algorytmów kryptograficznych/hashujących: używaj gotowych bibliotek napisanych przez specjalistów.

Security through obscurity w pełnej okazałości. Nie, nie możesz zakładać, że atakujący nie poza kodu użytego podczas hashownia. Ma takie same szans na zdobycie kodu aplikacji jak i na zdobycie zrzutu/dostępu do bazy danych. Zabezpieczenie ma polegać na tym, że nawet w przypadku gdy atakujący ma dostęp do wszystkich danych poza oryginalnym hasłem nie będzie wstanie złamać hasła.
Zawsze powinieneś zakładać najgorszą z możliwych sytuacji, czyli taką w której atakujący ma nieograniczony dostęp do danych.
Jeżeli zrozumiałeś już błąd w swoim rozumowaniu to wiesz, że w obu przypadkach atakujący kod(y) oraz sposób ich połączenia z oryginalnym hasłem (ze źródła aplikacji).
Opcja z pojedynczym kodem ma dwie podstawowe wady: 1) Wystarczy wygenerować jedną tablicę (metodą słownikową czy brute-forcem) i już mamy niemal gwarantowany dostęp kilku(nastu) procent kont w serwisie - bo tyle kont będzie miało hasło pokroju "haslo2" czy "abcde"; 2) Jeżeli dwóch lub więcej użytkowników przypadkiem będzie miało takie samo hasło będą oni mieli również identyczny hash hasła.
Co w przypadku gdy mamy unikalną/losową sól dla każdego? Po pierwsze użytkownicy z takim samym hasłem będą mieli inny hash hasła. Po drugie - i co ważniejsze - zamiast generować jedną tablicę na całą bazę danych będziemy musieli wygenerować ją dla każdego pojedynczego użytkownika z osobna. Innymi słowy metoda z generowaniem tablic odpada dla atakującego, ponieważ jest bardziej kosztowna od bezpośredniego ataku słownikowego/brute-force'a.

A ile trwa wygenerowanie tablicy tęczowej? To zależy od użytego algorytmu hashowania. I właśnie dlatego MD5 czy SHA-1/-2 (256, 512) są złym rozwiązaniem. Procesor mojego laptopa wartego 2000 zł jest wstanie policzyć kilkaset tysięcy hashy MD5 na sekundę. Ten sam laptop jest wstanie policzyć kilkanaście-kilkadziesiąt hashy wykorzystujących m.in. blowfisha i odpowiednio przygotowaną sól. Co to oznacza? Oznacza to, że wygenerowanie tablicy tęczowej jest nieopłacalne, a jeżeli mielibyśmy to jeszcze powtarzać dla każdego użytkownika z osobna praktycznie niewykonalne. Ataki słownikowe/bf również stają się nieopłacalne.

Co do ciasteczek - tutaj niestety przejęcie ciasteczka właściwie równa się możliwości zalogowania się. Przejęcie nie jest specjalnie trudne, dlatego też ciastko nie powinno zawierać żadnych danych - jedynie losowy ciąg (ew. id użytkownika). Po każdorazowym zalogowaniu przy użyciu tego ciasteczka powinieneś je nadpisywać z nowym kodem deaktualizując stary. Sama aplikacja powinna zaś umożliwić użytkownikowi po zalogowaniu się deaktywację wszystkich istniejących kluczy "zapamiętaj mnie". Dodatkowa tabela w bazie danych z ID użytkownika, kluczem i datą dodania do bazy danych nie kosztuje Cię kompletnie nic.

EDIT:Oczywiście BlowFish to szyfr symetryczny i w żadnym wypadku nie powinno się go w takiej formie używać do przechowywania haseł - trochę niefortunny skrót myślowy z mojej strony.
Powiedzmy, że do przechowywnia haseł został użyty algorytm, który generuje hash w 0.05 sekundy (a spokojnie można pokusić się o 0.1 - 0.3 sekundy), a nie 0.000015 (np. taki MD5). Powiedzmy, że 2-3 dni na wygenerowanie tablicy można sobie spokojnie poczekać. Ale 666-999 dni, bądź 199800-332667 dni przy założeniu, że każdy ma unikalną sól (~550-~1000 lat) już nie bardzo. A w przykładzie założyłem, że w bazie jest raptem 3000 użytkowników.

Na koniec: zauważcie, że utrudnienie złamania hasła można podnieść nie kilkukrotnie, ale o kilka rzędów wielkości praktycznie zerowym kosztem w 5 minut.

Ten post edytował Crozin 30.07.2012, 22:34:32

Zacznie od kont adminów i redaktorów. A może hybryda: hasło + kod wspólny + kod osobny?

Po coś w końcu wprowadzili funkcję kart prywatnych w przeglądarkach. Nawet gdy internauta zaznaczy "zapamiętaj mnie", po zamknięciu karty ciastko powinno zniknąć, a w bazie nie będzie śmieci. No chyba że zapisujemy historię logowań i chcemy ją trzymać na stałe. Niestety, większość nie wie o istnieniu takiej funkcji. Nie ma znaczenia, co będzie w ciasteczku - na tym samym komputerze każdy ma dostęp do konta.

Tu widać przewagę unikalnego ID zamiast hasła w ciastku, tylko znów - kto będzie świadomy, że jest zalogowany na publicznym komputerze i skorzysta z deaktywacji? Swoją drogą tabelka z listą komputerów, gdzie użytkownik jest zalogowany, to bardzo przydatna funkcja. W przypadku hasła w ciastku można zmienić hasło lub klucz.

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

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Ś.

Ten post edytował WebCM 31.07.2012, 00:58:16

Tak, to może być dobre rozwiązanie - na pewno nie zaszkodzi.
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).
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.
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.

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:



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.

Jeśli wycieknie baza, atakujący pozna wszystkie unikalne kody zalogowanych użytkowników. Wystarczy mieć taki sam adres IP, co w miejscach publicznych jest możliwe. Zmiana ID przy każdej wizycie nie pomoże, bo włamanie może nastąpić wcześniej. Mam kilka komputerów z tym samym IP, systemem, przeglądarką, chcę być na każdym zalogowany i tu pojawia się problem, bo po zmianie ID automatycznie zostanę wylogowany na innych. Można zapisywać adres MAC, ale nie wszędzie da się go uzyskać. Zmienię przeglądarkę na nowszą i znów wylogowany, bo User-Agent inny.

Gdzieś czytałem że korzystanie z mało popularnych algorytmów hashujących jest niebezpieczne.
Rzadko używany równa się kiepsko przetestowany i możliwe że całkowicie dziurawy.

Które to algorytmy w ten sposób padły? MD4 i chyba coś jeszcze. Wszyscy myśleli że jest super bezpiecznie, algorytm stawał się numerem jeden, aż któregoś dnia przychodził zdolny kryptolog i łamał go w 15 minut na serwetce.

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.

Do autoryzacji można użyć też GeoIP, Google czasem marudzi(ł) że naglę łączę się z innego miasta i prosił o ponowną autoryzację