Jak to jest z tym bezpieczeństwem dla MD5

Witam

większość z Nas wie, że kodowanie za pomocą MD5 w PHP jest jednostronne, ale wystarczy trochę poszperać w sieci i natrafiamy na takich osiłków:

Odp: [MD5]Kodowanie / Dekodowanie MD5

Dekodowanie MD5 polega na znalezieniu ciągu, który po zakodowaniu da taki sam hash jak ten, który posiadamy. MD5 jest 32 bitowy, tak więc fakt, że ilość możliwych hashy jest ograniczona nikogo chyba nie dziwi Oczywiście uzyskany ciąg jest niekoniecznie identyczny z tym, którego tak naprawdę szukamy. Metoda dopiero powstaje

Inne źródła wskazują na podobne tematy, także związane z SHA-1 Co o tym myślicie ? bo nawet jeśli kodowany tekst, który będzie zawierał : email, login user'a i czas (zakładając tylko) może i tak nic nie dać

Dla niedowiarków :) dokładam wspomniane wcześniej inne źródła :

MD5 da się złamać, naturalnie nie jest to proste (tak, czy siak siłowo albo szukając w tabeli), ale jednak. Ataki na MD5 notuje się z powodzeniem od 1994 roku. Udało się np. podrobić podpis cyfrowy RAPID SSL (do generawania podpisu używany był MD5 właśnie) tak, że możliwe stało się wystawianie kolejnych certyfikatów za jego pomocą (nie jest tu istotne czy dało się je weryfikować w ośrodku certyfikacyjnym). Fakt faktem, tak zwane kolizje istnieją i stanowią dziurę w algorytmie - poczytajcie o ataku urodzinowym. Pozdrawiam.

lub

http://pl.wikipedia.org/wiki/T%C4%99czowe_tablice

Jeśli nie MD5, to co ? Jak dla mnie to większość haseł w sieci jest kodowana za pomocą tej funkcji...

W ogólnym przypadku nie da się odwrócić MD5, jeśli masz dość długie hasło to jakiś tam algorytm typu brute-force może ewentualnie znaleźć ciąg znaków ASCII, który będzie się haszował do zadanej wartości, ale nijak nie będzie przypominał oryginalnego hasła. Generalnie haszuje się i soli hasła po to, aby tych haseł czystym tekstem nie wykradł haker, który włamie się na serwis.

Jeśli chcesz zwiększyć bezpieczeństwo to po prostu używaj dłuższych haszy np SHA-512.

Aby ochronić samo zhaszowane hasło musiałbyś generalnie wymagać entropii hasła (znacznie) większej niż entropia hasza (MD5 to 128-bitów). Wtedy jest duże (odpowiednio: prawie pewne) prawdopodobieństwo, że atakujący znajdzie jakiś inny ciąg ASCII haszujący się do zadanego hasza niż oryginalne hasło.

Jeśli nie znamy hasha, to i najlepsze metody łamania MD5 nam nie pomogą.
Hash może "wyciec" z bazą danych, vide historia wykop.pl. Rozwiązaniem (częściowym!) jest solenie, czyli dorzucanie do hashu nie tylko hasła, ale i innych wartości. Wtedy nawet znajomość kolizji nam nie pomoże, bo możemy sprawdzić czy części hasła są poprawne. Plus, solenie może zmniejszyć szybkość wyliczania hashy.

Kolizje to nie "dziura w algorytmie", ale matematyczna własność funkcji skrótu, której się raczej nie da pozbyć.

Rozwiązanie po stronie serwisu internetowego: zabezpieczenie dostępu do bazy danych, brak dziur w skrypcie aby można było do bazy się dostać, hashowanie i solenie haseł. Ewentualnie zmiana algorytmu z MD5 na coś dłuższego, np. SHA-256 (bo SHA-256 jest wolniejsza od MD5, więc i potencjalny atak brute-force będzie trwał dłużej).

Rozwiązanie po stronie użytkownika: unikalne, trudne hasło. Unikalne by przejęcie nawet jednego konta nie uczyniło podatnych kolejnych kont. Trudne, aby "tęczowe tablice" i prosty atak słownikowy były nieopłacalne.

a ja z innej beczki

Najpierw co mi się wydaje, że wiem :p

1. php działa po stronie serwera i żeby móc w nim zrobić cokolwiek z jakąkolwiek zmienną MUSI ona przebyć drogę od przeglądarki do serwera
2. w przeglądarce wpisujemy 'gołe', niezahashowane hasło
   3a. instaluje się nam na kompie jakiś badziew, który podgląda co leci po sieci
   3b. albo ktoś (jakiś hakjer, czy inna tego typu bestyja) przechwytuje pakiety lecące z przeglądarki do serwera
3. ma gołe hasło. Mówimy na razie o połączeniu nieszyfrowanym

Jeśli powyższe jest prawdą to ja się pytam po jaki **** wszyscy się podniecają hashowaniem haseł przez PHP po stronie serwera? Co to komu daje? Jeśli zrobimy hashowanie po stronie przeglądarki (np. javascript) to mamy dwa problemy - ktoś może mieć przeglądarkę bez js i/lub cały system solenia hasła bierze w łeb bo sól można podejrzeć w przeglądarce.

A teraz jeśli połączenie mamy szyfrowane to po co w ogóle bawić się z hashowaniem haseł? Przecież wszystko leci i tak zaszyfrowane. Trzymanie w bazie zahashowanych haseł bo ładnie wyglądają to głupota. Jak ktoś się dostanie do bazy to będzie miał głęboko w *** hasła bo albo ściągnie sobie całą bazę albo sobie w niej coś doda/zmieni albo po prostu usunie.

Zamiast tak się podniecać hashami lepiej po pierwsze zadbać o to aby fizyczny serwer był bezpieczny i aby połączenie z nim było szyfrowane. Hashowanie po stronie serwera haseł to porażka. Jedyne utrudnienie to hashowanie po stronie przeglądarki ale to utrudnienie a nie rzeczywista przeszkoda nie do obejścia.

Tyle moich wynurzeń trochę obok tematu.

Hashowanie po stronie serwera to po prostu minimalizacja skutków ewentualnego włamania. Chciałbyś żeby z twojego serwisu wyciekło kilka milionów haseł plaintekstem zamiast wybranych paru tysięcy? Obecnie hashowanie czymś mocnym + sól + SSL to można powiedzieć "standard bezpieczeństwa".

• Wychodzę z założenia że większość userów jest głupia i nie potrafi zadbać o swoją prywatność podając wszędzie ten sam email i używając wszędzie tego samego hasła.

Misiekd - dzięki właśnie tego oczekiwałem, o to mi chodziło. Pierwsze co mi przyszło do głowy to oczywiście, jak to nazywacie "solenie", ale skłaniałem się bardziej ku SHA-1 niż MD5

Faktem jest, że nie ma sensu bawić się hasłami, bo PHP działa po stronie serwera- tak, jak już to tutaj wspominano. Dobrze jednak, że ktoś napisał to wprost- czasami najprostsze rzeczy najtrudniej dostrzec

Suma sumarum, uważam jednak, że lepiej haszować niż nie haszować :)

Demonical Monk napisał(a)

Chciałbyś żeby z twojego serwisu wyciekło kilka milionów haseł plaintekstem

no właśnie chodzi o to, żeby nie wyciekły ŻADNE, nieważne jak zapisane. Jeśli jednak wychodzimy z założenia, że jednak dane ktoś na ukradnie to hashowanie haseł ma jakiś tam sens.

zamiast wybranych paru tysięcy?

a tego nie kumam - co ma fakt zahashowania hasła do ilości skradzionych danych?

dokładnie
poza tym atak po stronie klienta to atak na jednego użytkownika i ten użytkownik sam sobie jest temu winien
wyciek tysięcy haseł to wina serwisu i poważna sprawa ze względu na to że większość użytkowników używa tego samego hasła wszędzie, więc zmusza ich to do ich zmiany
przecież nie po to się kradnie hasła żeby się włamać z ich pomocą do serwisu z którego się je ukradło :|

a tego nie kumam - co ma fakt zahashowania hasła do ilości skradzionych danych?

z zahashowanych haseł uda się odzyskać tylko niewielki procent w skończonym czasie, z niezahashowanych mamy wszystkie od razu

no właśnie chodzi o to, żeby nie wyciekły ŻADNE, nieważne jak zapisane. Jeśli jednak wychodzimy z założenia, że jednak dane ktoś na ukradnie to hashowanie haseł ma jakiś tam sens.

ma ogromny sens - właśnie przez takich programistów jak Ty z za dużym ego wszystkie wycieki haseł miały w ogóle miejsce
bo przecież "jestem geniuszem i nie ma szans żeby w moim skrypcie była jakaś dziura"... a mimo to wycieki haseł mają regularnie miejsce i to z dużych serwisów
np w gg hasła mają zapisane w bazie plaintekstem - jeszcze nikt się do nich wprawdzie nie dobrał (chyba że mnie coś ominęło), ale tak naprawdę wszyscy pracownicy gg mają do nich prosty dostęp

Ilość skradzionych danych jest taka sama, tylko czas potrzebny na przygotowanie ich do ewentualnego wykorzystania gwałtownie wzrasta - i o to chodzi. Potencjalnie zanim większość hashy zostanie złamana userzy powinni zostać powiadomieni i pozmieniać swoje hasła.

Nie możemy nigdy założyć że mamy na tyle zajebisty serwis że nic nam nie wycieknie. Przecież włamanie może wystąpić nawet przez zero-day w usługach lub kernelu - wyciekły z Sony, nie wyciekną z twojego serwisu? Bzdura. Utrudnień jednak nigdy za wiele - sama kwestia przechowywania hashowanego hasła w bazie niczego zbytnio nie utrudnia, a jednak jakieśtam większe bezpieczeństwo zapewnia.

unikalna_nazwa napisał(a)

atak po stronie klienta to atak na jednego użytkownika i ten użytkownik sam sobie jest temu winien

większość użytkowników używa tego samego hasła wszędzie

a to przepraszam jest wina serwisu czy usera, że używa tego samego hasła wszędzie? Przecież dokładnie to stwierdzenie można podpiąć do Twojego stwierdzenia, które zacytowałem jako pierwsze.

Generalnie nie neguję hashowania jako takiego. Neguję jedynie fakt wyolbrzymiania go (hashowania) do rangi leku na całe zło. Jak już napisałem wcześniej - ŻADNE dane nie powinny nigdzie 'wyciekać', nieważne czy w postaci otwartego tekstu, zahashowane czy zaszyfrowane. Jeśli autor serwisu wychodzi z założenia, że dane 'wyciekną' to coś tu jest nie tak.

Misiekd napisał(a)

Jeśli autor serwisu wychodzi z założenia, że dane 'wyciekną' to coś tu jest nie tak.

Musi wychodzić z takiego założenia. Nie wiadomo czy gdzieś nie ma zero-daya - chociażby w kernelu czy jakiejś usłudze o której nie mamy pojęcia. Nigdy nie wiesz co się przydarzy, nigdy nie dowiesz się ile jest nieodkrytych luk w oprogramowaniu, a czasem nawet błędów w sprzęcie. Środków minimalizujących skutki włamania (różnorakich) jak najbardziej powinno się używać i jednym z nich jest właśnie silny hash z solą. Metod jest wiele - oczywiście zakładam że projektują aplikację ludzie trzeźwo myślący i zadbają również o zabezpieczenie aplikacji i środowiska samego w sobie. Nie bagatelizowałbym tego, że "to użytkownika sprawa jakie sobie hasła do innych serwisów ustawia" - jeśli możemy coś zrobić to trzeba chronić jego hasło od początku do końca, a nie do momentu złamania zabezpieczeń, albo w ogóle go nie chronić (w żaden sposób) skoro cię to nie obchodzi. Co do czego przyjdzie za swój brak zainteresowania bezpieczeństwem innych możesz oberwać karę w postaci miliarda artykułów o bezpieczeństwie w twoim portalu, a raczej jego braku.

unikalna_nazwa napisał(a)

właśnie przez takich programistów jak ty z za dużym ego wszystkie wycieki haseł miały w ogóle miejsce
bo przecież "jestem geniuszem i nie szans żeby w moim skrypcie była jakaś dziura"...

nigdzie nie napisałem nic o tym, że '...jestem geniuszem...' :). A idąc w drugą skrajność - właśnie przez takich programistów jak Ty, którzy twierdzą, że jak zahashują hasła i jeszcze je posolą to już ich nikt nie ruszy jednocześnie mając gdzieś samo bezpieczeństwo serwera jest tyle wycieków z różnych serwisów. Możemy się tak do usranej i generalnie będzie z tego ładny flame ale nie o to przecież chodzi.

Napiszę jeszcze raz

• Hashowanie po stronie PHP nie uchroni przed podejrzeniem hasła w drodze od przeglądarki do serwera
• Hashowanie haseł nie powoduje automatycznie tego, że są one nie do odczytania. Są one po prostu trudniejsze do odczytania i bardziej czasochłonne.
• Można przyjąć, że jak się ktoś dostanie do bazy to jest 50% szans, że dostał się też do kodu i wyciągnięcie też sól - solenie zwiększa poziom trudności i ilość czasu potrzebną do 'złamania hasła' ale po raz kolejny nie jest magicznym panaceum na sam fakt wykradzenia hasła
• No i na koniec co z innymi danymi, często dużo ważniejszymi niż samo hasło - adres, nr konta bankowego, nr karty kredytowej, itp? Hasło sobie zmienię a adres czy nr karty trochę trudno

Misiekd napisał(a)

Generalnie nie neguję hashowania jako takiego. Neguję jedynie fakt wyolbrzymiania go (hashowania) do rangi leku na całe zło. Jak już napisałem wcześniej - ŻADNE dane nie powinny nigdzie 'wyciekać', nieważne czy w postaci otwartego tekstu, zahashowane czy zaszyfrowane. Jeśli autor serwisu wychodzi z założenia, że dane 'wyciekną' to coś tu jest nie tak.

no to jest jedynie założenie i jego trzeba się trzymać, ale nie można być pewnym że się uda

jasne że wina usera, ale tak naprawdę już nie taka jak zainstalowanie u siebie keyloggera
większość ludzi w ogóle się nie zastanawia nad bezpieczeństwem i nie wpada na pomysł żeby wszędzie mieć inne hasło i to właściwie nie powinna być ich wina bo tym się powinni w miarę możliwości zajmować spece od bezpieczeństwa

a przecież nawet jeśli będziemy mieć połączenie szyfrowane to mało ludzi zdaje sobie sprawę że twórcy serwisu wcale nie muszą być tacy jak twórcy innych serwisów i mogą sobie po prostu hasła zbierać - atakującym może być sam twórca serwisu (podobnie jak Mark Zuckerberg który założył facebooka początkowo po to żeby zdobyć dane swoich koleżanek ze szkoły... ;))

a jeśli dane są naaaaaprawdę dużo warte to duża szansa że atak nie nastąpi przez Internet tylko przez serwerownię... (serwery allegro przykładowo są otoczone w serwerowni drutem kolczastym - ale czy to na dużo się zda przy ewentualnym ataku?)

podsumowując - nie da się skutecznie uchronić przed złem, ale można porozstawiać dużo przeszkód

nie widzę nic złego w hashowaniu hasła po stronie serwera jako podstawowego zabezpieczenia i nie przekonasz mnie że można spokojnie przechowywać hasła jawnie

No i na koniec co z innymi danymi, często dużo ważniejszymi niż samo hasło - adres, nr konta bankowego, nr karty kredytowej, itp? Hasło sobie zmienię a adres czy nr karty trochę trudno

z adresem ciężka sprawa - można jedynie chyba szyfrować, zabezpieczenie marne bo jeśli skrypt ma mieć w dowolnej chwili dostęp do tych danych to każdy inny też może
ale z drugiej strony adres to nie jest informacja jakoś szczególnie chroniona gdziekolwiek i raczej nie jest zbyt przydatna
nr konta bankowego raczej się nikomu na nic nie zda - jedynie może Ci dokonać wpłaty a potem oskarżać o łapówkarstwo jak to Kaczyński mawiał :D
a z tego co się orientuję jakaś norma unijna zakazuje zbierania kompletu danych dotyczących karty kredytowej wystarczających do dokonania płatności, więc ktoś może wykraść nr karty kredytowej ale znowu na za dużo mu się on nie przyda jeżeli nie będzie miał daty ważności i kodu CVC, który nie ma prawa być w tej bazie danych

zgadzam się z miśkiem, już kiedyś napisałem coś podobnego ale zostałem zlinczowany ;p niestety jednak od tego czy Twoje hasła wyciekną zależy za wiele rzeczy:
konfiguracja serwera, mysql, ftp, http, szczelności skryptu php i pewnie wielu innych rzeczy i zawsze się znajdzie jakiś as, który coś skopie w swoim programie i da tym samym dostęp do bazy i pewnie po to jest to całe hashowanie, żeby zabezpieczyć się przed błędami innych ;)

A przed własnymi błędami się nie zabezpieczasz, bo przecież sam piszesz idealny i bezbłędny kod?

Hashowanie po stronie PHP nie uchroni przed podejrzeniem hasła w drodze od przeglądarki do serwera

Od tego jest SSL.

Hashowanie haseł nie powoduje automatycznie tego, że są one nie do odczytania. Są one po prostu trudniejsze do odczytania i bardziej czasochłonne.

Hasz nie jest funkcją bijektywną, wiele ciągów ASCII (+ sól jeśli solimy) będzie haszować się do jednego i tego samego hasza. A więc ktoś może "odzyskać" hasło, które jest zupełnie niepodobne do oryginalnego, ale dalej wygląda jak normalne hasło. Jeżeli myślisz, że z hasza da się zawsze wyciągnąć oryginalne dane, to należysz do zbioru "geniuszy", którzy uważają, że wystarczy hasz obrazu Windowsa, aby odzyskać cały obraz Windowsa.

Można przyjąć, że jak się ktoś dostanie do bazy to jest 50% szans, że dostał się też do kodu i wyciągnięcie też sól - solenie zwiększa poziom trudności i ilość czasu potrzebną do 'złamania hasła' ale po raz kolejny nie jest magicznym panaceum na sam fakt wykradzenia hasła

Solenie jest po prostu środkiem przeciwko tęczowym tabelom i podobnym rozwiązaniom, typu przechowywanie par (hasło, hasz MD5), nic więcej.

No i na koniec co z innymi danymi, często dużo ważniejszymi niż samo hasło - adres, nr konta bankowego, nr karty kredytowej, itp? Hasło sobie zmienię a adres czy nr karty trochę trudno

Jeśli to są takie supertajne dane to możesz je zaszyfrować. Kluczem może być też hasz hasła, ale z inną solą, albo nawet hasz osobnego hasła.

Poza tym kiedyś czytałem, że IBM wymyślił sposób obsługi zapytań na zaszyfrowanych bazach danych bez deszyfrowania danych (a więc np baza mogła w ogóle nie mieć pojęcia o kluczu użytym do szyfrowania czy deszyfrowania, a i tak dalej działać jak należy). Wadą była niska wydajność, no ale jednak bezpieczeństwo było wyższe.

Pozostaje mi podziękować wszystkim, za tak burzliwą debatę :) Mam już pełniejszy obraz w tym temacie

Tak, funkcje hash są z założenia jednostronne. Jeżeli tekst jest dość długi to każdy nowoczesny algorytm hashujący zabezpieczy go przed odgadniciem orginału (md5 nie jest nowoczesny i nalpepiej jest przestać go używać). Jeżeli jednak hash jest reprezentacją hasła rzeczy maja sie troche innaczej. Istnieja serwisy które składują ogrome liczby haseł i ich hashów. Źrodłem ich są zazwyczaj slowniki oraz hasła które wyciekły z poprzednich haków. Jedny z takich serwisów jest np crypto.apitools.zone/md5-decode.html gdzie można spróbować "odwrócić" hash. Posiada on także API wiec można go użyć proramistycznie. Aby uniknąc tego typu ryzyka nalepiej jest używać hashu z solą co całkowicie eliminuje możliwość użycia tego typu tabel.