Jak to jest z tym bezpieczeństwem dla MD5

Odpowiedz Nowy wątek
2011-09-27 14:31
0

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

edytowany 1x, ostatnio: amator1, 2011-09-27 14:31

Pozostało 580 znaków

2011-09-27 15:01
1

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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2011-09-27 15:04

Pozostało 580 znaków

2011-09-27 15:18
0

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.

Pozostało 580 znaków

2011-09-27 15:36
0

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.


- Ciemna druga strona jest.
- Nie marudź Yoda, tylko jedz tego tosta.
Google NIE GRYZIE!
Pomogłem - kliknij
Który mi dał minusa?? Przyznawać się - Misiekd 2011-09-27 15:57
chyba ten "z różowym gejem na avatarze" - krwq 2011-09-27 16:09

Pozostało 580 znaków

2011-09-27 15:47
0

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.

Women were the reason I became a monk - and, ah, the reason I switched back...
edytowany 1x, ostatnio: Demonical Monk, 2011-09-27 15:48

Pozostało 580 znaków

2011-09-27 15:55
0

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ć :)

edytowany 1x, ostatnio: amator1, 2011-09-27 16:04

Pozostało 580 znaków

2011-09-27 15:56
0
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?


- Ciemna druga strona jest.
- Nie marudź Yoda, tylko jedz tego tosta.
Google NIE GRYZIE!
Pomogłem - kliknij

Pozostało 580 znaków

2011-09-27 15:57
0

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


Pół giga extra na dropboxie? Pół giga extra na dropboxie! Tyle wygrać! >>Klik here<<
edytowany 4x, ostatnio: unikalna_nazwa, 2011-09-27 16:22

Pozostało 580 znaków

2011-09-27 16:00
0

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.


Women were the reason I became a monk - and, ah, the reason I switched back...
edytowany 1x, ostatnio: Demonical Monk, 2011-09-27 16:01

Pozostało 580 znaków

2011-09-27 16:02
0
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.


- Ciemna druga strona jest.
- Nie marudź Yoda, tylko jedz tego tosta.
Google NIE GRYZIE!
Pomogłem - kliknij

Pozostało 580 znaków

2011-09-27 16:10
1
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.


Women were the reason I became a monk - and, ah, the reason I switched back...
edytowany 2x, ostatnio: Demonical Monk, 2011-09-27 16:12

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0