![]() |
![]() ![]() |
![]() |
![]()
Post
#41
|
|
![]() Grupa: Zarejestrowani Postów: 382 Pomógł: 22 Dołączył: 21.05.2007 Skąd: Elbląg Ostrzeżenie: (0%) ![]() ![]() |
czy to przypadkiem nie jest jedna z teczowych tablic? |
|
|
![]()
Post
#42
|
|
![]() Admin Techniczny Grupa: Administratorzy Postów: 2 071 Pomógł: 93 Dołączył: 5.07.2005 Skąd: Olsztyn ![]() |
cos w ten desen ale przy 12 znakach nie znalazł hasha
![]() |
|
|
![]()
Post
#43
|
|
![]() Grupa: Zarejestrowani Postów: 382 Pomógł: 22 Dołączył: 21.05.2007 Skąd: Elbląg Ostrzeżenie: (0%) ![]() ![]() |
jednym słowem jeszcze daleko brakuje do łamacza hashów z prawdziwego zdarzenia...
|
|
|
![]()
Post
#44
|
|
Grupa: Zarejestrowani Postów: 120 Pomógł: 12 Dołączył: 9.10.2008 Skąd: Tricity.Rumia() Ostrzeżenie: (0%) ![]() ![]() |
Witajcie ... to mój pierwszy post na tym forum więc tym bardziej witam ;-)
Chciałbym dorzucić swoje trzy grosze ;] (podsumowując powyższą dyskusję) 1. (pierwszy grosz) n-hashowanie nie ma żadnego znaczenia przy ataku bf - zdalnym 2. (drugi grosz) - Jeżeli hacker wszedł w posiadanie naszej bazy danych jednak nie ma dostępu do źrodeł PHP w takiej sytuacji n-hashowanie daje hackerowi dodatkowy problem - odgadnięcie algorytmu hashowania - co powoduje że hasła są nie do złamania ![]() 3. (trzeci grosz) - hacker zna nasz algorytm i zna hashe - w tej sytuacji wielokrotne hashowanie również zwiększa bezpieczeństwo haseł(jawnych) ... Dlaczego? Dlatego że obliczenie sumy trwa ... i od czasu tego generowania zalezy ile możliwości zostanie sprawdzonych w ciągu sekundy. sprawdzenie wszystkich hashy 4 literowych przy algorytmie md5(md5($ciag)) bedzie trwało dwa razy dłużej niż md5($ciąg) - możliwe - nie analizowałem dokładnie funkcji liczącej hasha - ze czas potrzebny na md5(md5($ciag)) będize kilkakrotnie dłuższy niż md5($ciag) bo $ciąg ma 4 znaki a md5($ciąg) 32 znaki. między innymi na tym polega bezpieczeństwo WPA2 ( WiFi) tam hasło z tego co pamiętam jest hashowane 16 razy. W jakiś zawodach hacker który stworzył sobie Rainbow Tables wygrał bo przy kolejnych włamach tylko sprawdzał hasła - bez ich generowania ( tam hash liczony jest lokalnie ) Jeśli chodzi o kolizje to rzeczywiści md5 jest na nie podatne - jednak z logicznego punktu widzenia jeżeli md5 hash jest 32 znakowy to kolizje będą pojawiać się dopiero przy kodowaniu ciągów dłuższych niż 32 znaki ... dlatego wielokrotne hashowanie ciągów 32 znakowych nie powinno powodować kolizji choć pewnie znaczenie ma tutaj także zakres znaków |
|
|
![]()
Post
#45
|
|
![]() Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) ![]() ![]() |
1. Dwukrotne wydłużenie czasu potrzebnego do złamania to żadne wydłużenie. Podzielę zbiór haseł na dwa, puszczę proces równolegle na dwóch komputerach i po sprawie.
2. Jedyne, co może zrobić podwójne haszowanie, to zwiększyć podatność funkcji na kolizje. Załóżmy, że mamy takie wiadomości A, B, że H( A ) = H( B ). Wiemy, że istnieją takie z zasady szufladkowej (skończona ilość haszów, nieskończona ilość tekstów). Możemy też znaleźć dwie inne wiadomości C, D takie, że H( C ) = H( D ). Przy pojedynczym haszowaniu mamy dwie różne kolizje: algorytm, który wygeneruje A, podczas gdy hasz jest H©, będzie szukać dalej. Przypuśćmy teraz, że haszujemy oba hasze i okazuje się, że one ze sobą kolidują: H(H( A )) = H(H( C )). Nie można zakładać niemożliwości takiej sytuacji, bo niby czemu? Stworzę sobie z sha1 poprawną funkcję haszującą, która dla każdego 40-znakowego ciągu daje 40 liter "a" w wyniku i wtedy wszystkie hasze będą ze sobą kolidować ![]() Ten post edytował Zyx 14.10.2008, 07:21:44 -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
![]()
Post
#46
|
|
Grupa: Zarejestrowani Postów: 120 Pomógł: 12 Dołączył: 9.10.2008 Skąd: Tricity.Rumia() Ostrzeżenie: (0%) ![]() ![]() |
1. Dwukrotne wydłużenie czasu potrzebnego do złamania to żadne wydłużenie. Podzielę zbiór haseł na dwa, puszczę proces równolegle na dwóch komputerach i po sprawie. Idąc dalej tym tokiem rozumowania można stwierdzić że hashowanie wogole nie jest potrzebne ... zawsze istnieje pewna skończona liczba komputerow przy ktorej haslo da sie złamać. Co do podatnosci na kolizje zgodze sie ze moze sie zwiekszyc przy podwojnym hashowaniu - ale jest to tylko hipoteza. Jak pisałem nie analizowałem algorytmu md5 i nie wiem czy prawdopodobieństwo kolizji jest większe dla ciągów o tej samej długości czy o różnej. Stworzę sobie z sha1 poprawną funkcję haszującą, która dla każdego 40-znakowego ciągu daje 40 liter "a" w wyniku i wtedy wszystkie hasze będą ze sobą kolidować stworzę sobie poprawną funkcję hashującą która dla kazdego 40 literowego ciągu da inny 40 literowy ciąg ...
|
|
|
![]()
Post
#47
|
|
![]() Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) ![]() ![]() |
Kurde, jak do czegoś został przedstawiony poprawny dowód, to nie może być to hipotezą. n-krotne haszowanie co najwyżej pozostawia odporność na kolizje na niezmienionym poziomie lub ją pogarsza i jest to udowodniony fakt dla każdej istniejącej funkcji haszującej, jaką sobie wymyślisz. Natomiast od rodzaju samej funkcji zależy jedynie, jak bardzo sprawa może się pogorszyć, w szczególnym przypadku - może pozostać bez zmian.
A pozostaje bez zmian tylko i wyłącznie wtedy, gdy H(k) dająca n-znakowy ciąg jest bijekcją dla każdego k o długości dokładnie n. Lecz jeśli jest bijekcją, to wtedy istnieje jednoznaczna funkcja odwrotna. I aby Cię zmartwić, najłatwiej dowieść bijekcji właśnie znajdując funkcję odwrotną. O MD5 i SHA1 nic takiego nie wiemy i teraz są dwa wyjścia: 1. Albo przyjmujemy, że generują one kolizje dla 32- lub 40-znakowych ciągów, tym samym pogarszając odporność na kolizje. 2. Albo przyjmujemy, że nie są i wtedy cała nasza robota na nic, bo jak ktoś znajdzie funkcję odwrotną, co będzie tylko kwestią czasu, to z naszego podwójnego hasza bez trudu wyliczy sobie na początku pracy pojedynczy i cały Twój pomysł ze zwiększaniem ilości czasu/komputerów możesz wyrzucić na śmietnik. Tak więc najlepiej do naszego hasła dokleić losową i jawną sól, by zabezpieczyć się przed tęczowymi tablicami i zahaszować RAZ. Drugi hasz i więcej albo ułatwi zadanie łamaczowi, albo w najlepszym przypadku nie da nam NIC. PS. Pomysł ze zwiększaniem ilości zasobów byłby bardziej sensowny, gdyby pogarszał rząd złożoności, np. n-krotny hasz powodowałby konieczność użycia n^2 komputerów, by zakończyć obliczenia w tym samym czasie. PS2. Spróbuję znaleźć kogoś, kto się zajmuje kryptografią i kryptoanalizą przynajmniej półzawodowo i skonsultować z nim cały problem. Ten post edytował Zyx 16.10.2008, 16:49:49 -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
![]()
Post
#48
|
|
Grupa: Zarejestrowani Postów: 120 Pomógł: 12 Dołączył: 9.10.2008 Skąd: Tricity.Rumia() Ostrzeżenie: (0%) ![]() ![]() |
Dobra muszę przyznać Ci rację ;]
Wielokrone hashowanie zwiększa podatność na kolizję - chyba że funkcja hashująca jest odwzorowaniem jednoznaczym ( nie lubie MD ;P ), a wiadomo że nie jest. W sprawie zwiększenia czasu łamania hasha - owszem dobrze by było znac sposób na nie liniowe zwiększanie czasu ale chyba raczej takiego nie ma ... zakładając że hacker nie dysponuje botnetem z 10^6 komputerów zwiększenie czasu potrzebnego nawet dwukrotnie - zawsze będzie utrudnieniem. Chyba wszyscy wiemy że w atakach typu bruteforce czas gra najistotniejszą rolę. Jeszcze nasunęło mi się takie pytanie: Czy podatność na kolizję zmniejsza bezpieczeństwo haseł jawnych ![]() |
|
|
![]()
Post
#49
|
|
![]() Grupa: Zarejestrowani Postów: 108 Pomógł: 0 Dołączył: 15.10.2006 Skąd: zewsząd :P Ostrzeżenie: (0%) ![]() ![]() |
Nie rozumiem po co cały ten szum. Moje zdanie jest takie:
Słabość MD5 polega na tym że wszyscy znają ten algorytm, dlatego teorytycznie da się go 'odhashować'. Jeśli więc utrudnić procedurę hashowania, np. dodając nowe znaki, zamieniając kolejność znaków, mieszając hashe, odcinamy hakerowi możliwość złamania szyfru bo nie wie on jak go złamać. |
|
|
![]()
Post
#50
|
|
Grupa: Przyjaciele php.pl Postów: 7 494 Pomógł: 302 Dołączył: 31.03.2004 Ostrzeżenie: (0%) ![]() ![]() |
|
|
|
![]()
Post
#51
|
|
![]() Grupa: Zarejestrowani Postów: 182 Pomógł: 14 Dołączył: 20.09.2008 Ostrzeżenie: (0%) ![]() ![]() |
@Michu
"Słabość MD5 polega na tym że wszyscy znają ten algorytm, dlatego teorytycznie da się go 'odhashować'." Nie jestem kryptologiem, ale na kryptografii trochę się znam. Wszyscy ludzie, którzy są/mogą być autorytetami w tej dziedzinie, uważają, że nie można w kryptografii podchodzić do tematu przez tzw. security by obscurity. Przynajmniej publicznie żaden szanowany/szanujący się specjalista nie popiera takiej metody. Algorytmy powinny być udostępniane każdemu zainteresowanemu właśnie dlatego, żeby ludzie mogli znajdować ich słabości i je udoskonalać. "Jeśli więc utrudnić procedurę hashowania, np. dodając nowe znaki, zamieniając kolejność znaków, mieszając hashe, odcinamy hakerowi możliwość złamania szyfru bo nie wie on jak go złamać." MD5 można rozbić – czyli: - mamy ciąg znaków A z którego robimy skrót X - szukamy takiego ciągu B którego skrót też będzie wynosił X. Przy hasłach takie działanie nie ma sensu – szansa na rozbicie MD5 jest wielokrotnie mniejsza niż na znalezienie hasła za pomocą metody bruteforce. To co proponujesz – wprowadzenie dodatkowych mini zmian w wyniku działania MD5 nie ma większego sensu. MD5 jest wystarczająco mocne do większości zastosowań – żaden szanujący się włamywać nie będzie próbował go rozbijać – coś takiego wymaga olbrzymiej mocy przerobowej. Może za 20 lat będziesz mógł rozbijać MD5 na jakiś większych maszynach – ale jeszcze pozostaje problem długości ciągu znaków – ciąg A może mieć 10 znaków, ale ciąg B może mieć kilkaset MB – ograniczenie długości znaków w polu wpisywania hasła może być dobrym pomysłem. Na Twoim miejscu przestałbym się przejmować ezoterycznymi problemami MD5 i zająłbym się szukaniem błędów w innym miejscu ![]() |
|
|
![]()
Post
#52
|
|
![]() Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) ![]() ![]() |
MD5 zostało złamane już kilka lat temu (w sierpniu 2004 dokładnie). Obecnie znane są metody, które pozwalają na znalezienie kolizji na domowym pececie w parę godzin. Dodam, że niedawno znaleziono także pewne luki w SHA-1, ale nawet po ich zastosowaniu potrzebny czas wykracza poza możliwości współczesnych komputerów.
Z drugiej strony, masz 100% racji, że siła obecnych systemów kryptograficznych tkwi w matematyce i jawności algorytmów. Eksperymentowanie na oślep i utajnianie algorytmu nie ma żadnego sensu, gdyż zdolny kryptoanalityk rozwali taki pomysł bardzo szybko. Szansa, że przez przypadek stworzymy coś naprawdę mocnego, jest nikła. Przeważnie sprawy tylko się pogorszą, a przykład widać w przesądzie, że H(H(k)) jest silniejsze niż H(k) ![]() Ten post edytował Zyx 18.10.2008, 22:22:10 -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
![]()
Post
#53
|
|
![]() Grupa: Zarejestrowani Postów: 182 Pomógł: 14 Dołączył: 20.09.2008 Ostrzeżenie: (0%) ![]() ![]() |
|
|
|
![]()
Post
#54
|
|
![]() Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) ![]() ![]() |
Ech, wystarczy w Google wpisać "MD5 collisions" i masz tyle źródeł, że głowa boli
![]() http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf - praca poświęcona jednemu z algorytmów wyszukiwania kolizji http://it.slashdot.org/article.pl?sid=05/11/15/2037232 - informacja o publikacji kodu źródłowego do wyszukiwania kolizji http://eprint.iacr.org/2006/105 - praca nt znajdowania kolizji MD5 w minutę na domowym pececie. Poza tym: - udało się wygenerować dwa sensowne pliki Postscript z tym samym haszem. - udało się wygenerować dwa różne certyfikaty X.509 z tym samym haszem. -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
![]()
Post
#55
|
|
![]() Grupa: Zarejestrowani Postów: 1 033 Pomógł: 125 Dołączył: 17.09.2005 Skąd: Żywiec Ostrzeżenie: (0%) ![]() ![]() |
Porównanie trzech metod przechowywania haseł jako hashe md5:
1. md5( HASLO )
2. md5( HASLO + SÓL )
3. md5( md5( HASLO ) )
Załóżmy teraz, że jakiś łotr dorwał się do hasha użytkownika Jimmy:dupa8. Nie ma jednak dostepu do kodu PHP, więc nie zna metody szyfrowania ani soli. Ma przed sobą jedynie 32-znakowy hash składający sie z cyfr i liter a-f, co wskazuje na algorytm md5 W 1. przypadku md5( dupa8 ) jest równy 1212121212. Po przepuszczeniu tego przez tęczowe tablice lub potraktowaniu brute-forcem łotr odgadł haslo dupa8 (lub inną kolizję). Po wpisaniu tego w formularzy łotr zalogował się na konto Jimmi'ego W 2. przypadku md5( dupa8#@r23T@f23NJOąąąĆóŁd;'\[:""{:ffs+SD:+@wD#~`ds2 ) jest równy 3434343434. Łotr przepuszcza to przez tęczowe tablice lub traktuje brute-forcem i znajduje kolizję: Yx2;4óę8&Z$. Łotr jest nieco zdziwiony stopniem skomplikowania hasła, ale postanawia wpisać je w formularzu. Niestety nie udaje mu się zalogować na konto Jimmi'ego: Kod md5( dupa8 . SÓL ) == 3434343434 md5( Yx2;4óę8&Z$ . SÓL ) == 5656565656 3434343434 != 5656565656 md5( dupa8 . SÓL ) != md5( Yx2;4óę8&Z$ . SÓL ) W 3. przypadku md5( md5( dupa8 ) ) jest równy 7878787878. Łotr przepuszcza ten hash przez tęczowe tablice lub traktuje brute forcem i znajduje kolizję: 112ó�GHG:s\. Łotr jest nieco zdziwiony stopniem skomplikowania hasła, ale postanawia wpisać je w formularzu. Niestety nie udaje mu się zalogować na konto Jimmi'ego: Kod md5( md5( dupa8 ) ) == 7878787878 md5( 112ó�GHG:s\ ) == 7878787878 ALE: md5( md5( 112ó�GHG:s\ ) ) == 9090909090 7878787878 != 9090909090 md5( md5( dupa8 ) ) != md5( md5( 112ó�GHG:s\ ) ) Wynika z tego, że: - Stosowanie hashowania z SOLĄ lub podwójnego hashowania jest bezpieczniejsze niż zwykłe pojedyncze hashowanie md5 - Stosowanie 50-krotnego hashowania jest tak samo dobre jak stosowanie 10-krotnego hashowania, które jest tak samo dobre jak stosowanie 2-krotnego hashowania. Czyli tworzenie potworków w stylu: md5( md5( md5( md5( md5( md5( md5( md5( md5( md5( dupa8 ) ) ) ) ) ) ) ) ) ) jest kompletnie bezcelowe. PS. Jako że nie jestem ekspertem od kryptografii chciałbym, aby ktoś udowodnił mi, że powyższe rozumowanie jest błedne. Ten post edytował Kicok 20.10.2008, 18:38:34 -------------------- "Sumienie mam czyste, bo nieużywane."
|
|
|
![]()
Post
#56
|
|
![]() Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) ![]() ![]() |
Punkt 1, 2 - są w porządku.
Punkt 3 - przeczytaj to, co jest napisane powyżej. Niemieccy wojskowi też wierzyli, że utajniając algorytm działania Enigmy ich szyfry są nie do złamania. Myślisz, że atakujący byłby na tyle głupi, by nie poszukać też kolizji wśród ciągów o długości 32 znaków? Myślisz, że twórcy tęczowych tablic nie wiedzą o możliwości podwójnego zahaszowania i nie wprowadzają do nich zahaszowanych wersji haszów? -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
![]()
Post
#57
|
|
Grupa: Przyjaciele php.pl Postów: 7 494 Pomógł: 302 Dołączył: 31.03.2004 Ostrzeżenie: (0%) ![]() ![]() |
PS. Jako że nie jestem ekspertem od kryptografii chciałbym, aby ktoś udowodnił mi, że powyższe rozumowanie jest błedne. Oczywiście że jest błędne. Jest po prostu sprzeczne, więc nawet nie ma co się wyslilać żeby pokazać błąd ![]() Spójrz co piszesz: - Stosowanie (...) podwójnego hashowania jest bezpieczniejsze niż zwykłe pojedyncze hashowanie md5 (...) tworzenie potworków w stylu: md5( md5( md5( md5( md5( md5( md5( md5( md5( md5( dupa8 ) ) ) ) ) ) ) ) ) ) jest kompletnie bezcelowe. Raz twierdzisz co innego a później cos innego. Zdecyduj się co chcesz pokazać.Tak czy inaczej wielokrotne (dwa to też więcej niż jeden) haszowanie nie ma sensu. Niemieccy wojskowi też wierzyli, że utajniając algorytm działania Enigmy ich szyfry są nie do złamania. Haha, no właśnie. ardzo dobry przykład. Kluczem do złamania Enigmy były jej dodatkowe zabezpieczenia, które osłabiły całość.
|
|
|
![]()
Post
#58
|
|
![]() Grupa: Zarejestrowani Postów: 1 033 Pomógł: 125 Dołączył: 17.09.2005 Skąd: Żywiec Ostrzeżenie: (0%) ![]() ![]() |
Cytat("mike") Oczywiście że jest błędne. Jest po prostu sprzeczne, więc nawet nie ma co się wyslilać żeby pokazać błąd Spójrz co piszesz: Cytat("Kicok") - Stosowanie (...) podwójnego hashowania jest bezpieczniejsze niż zwykłe pojedyncze hashowanie md5 Cytat("Kicok") (...) tworzenie potworków w stylu: md5( md5( md5( md5( md5( md5( md5( md5( md5( md5( dupa8 ) ) ) ) ) ) ) ) ) ) jest kompletnie bezcelowe. Raz twierdzisz co innego a później cos innego. Zdecyduj się co chcesz pokazać. Tak w skrócie to napisałem powyżej: - Stosowanie 2-krotnego hashowania jest bezpieczniejsze niż pojedyńcze hashowanie - Stosowanie 50-krotnego hashowania jest tak samo bezpieczne, jak 2-krotne hashowanie, więc stosowanie potworków typu: md5( md5( md5( md5( md5( dupa8 ) ) ) ) ) jest bezcelowe (w domyśle: można stosować po prostu md5( md5( dupa8 ) ) ) Ja tu nie widzę żadnej sprzeczności. Cytat("mike") Tak czy inaczej wielokrotne (dwa to też więcej niż jeden) haszowanie nie ma sensu. Załóżmy, że md5( md5( dupa8 ) ) jest równe 1212121212. Po potraktowaniu tego hasha brute-forcem otrzymamy kolizję q@w#E$5. Po wpisaniu tego w formularzu znowu wykonywane jest podwójne hashowanie: md5( md5( q@w#E$5 ) ), ale logowanie nie powiedzie się, ponieważ hash w tym przypadku NIE JEST równy 1212121212. BYŁBY, gdybyśmy zrobili samo: md5( q@w#E$5 ). Jeśli łotr zorientowałby się, że zastosowano podwójne hashowanie, musiałby: a.) odnaleźć kolizję z zakresu 0x00000000000000000000000000000000 - 0xffffffffffffffffffffffffffffffff (w najrogszym wypadku 16^32 prób) b.) odnaleźć kolizję kolizji LUB a.) skorzystać z tęczowych tablic, jeśli rzeczywiście są one tak rozbudowane, że przechowują także hashe hashy. W takim przypadku faktycznie podwójne hashowanie nie zwiększa praktycznie w ogóle poziomu bezpieczeństwa. EDIT PS1. Oczywiście jeśli kolizje haseł hashowanych podwójnie można odczytać z tęczowych tablic, to stwierdzenie, że 50-krotne hashowanie jest tak samo silne jak 2-krotne jest nieprawdziwe PS2. Nadal podtrzymuję prośbę, żeby mi ktoś łopatologicznie wyjaśnił dlaczego się mylę twierdząc, że podwójne hashowanie jest bezpieczniejsze niż pojedyńcze. Bo jak na razie została mi wytknieta sprzeczność tam, gdzie jej nie widzę oraz zostałem ochrzaniony za to, że nie wiedziałem, że w tęczowych tablicach są hashe hashów. PS3. Skoro jednak są hashe hashów w tęczowych tablicach, to czy potrójne hashowanie jest bezpieczniejsze niż pojedyńcze? A jeśli w tęczowych tablicach są też hashe hashów hashów, to ile gigabajtów zajmuje taka tablica (dla haseł alfanumerycznych 1-8 znakowych )? Ten post edytował Kicok 21.10.2008, 11:04:40 -------------------- "Sumienie mam czyste, bo nieużywane."
|
|
|
![]()
Post
#59
|
|
![]() Grupa: Moderatorzy Postów: 36 455 Pomógł: 6292 Dołączył: 27.12.2004 ![]() |
Cytat Po potraktowaniu tego hasha brute-forcem Brute force wykonuje sie zazwyczaj na aplikacji, wiec aplikacja bedzie przepuszczala to przez podwojne hashowanie ![]() -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
![]()
Post
#60
|
|
![]() Grupa: Zarejestrowani Postów: 1 033 Pomógł: 125 Dołączył: 17.09.2005 Skąd: Żywiec Ostrzeżenie: (0%) ![]() ![]() |
O i taka odpowiedź rozjaśniła mi już wiele.
Teraz tylko muszę dojść do tego, dlaczego sam o tym nie pomyślałem, tylko kombinowałem na około z wykrywaniem kolizji kolizji-32-znakowych ![]() Zakładając teraz, że łotr może założyć sobie konto w danym serwisie i podejrzeć swój własny hash w bazie, może łatwo odgagnąć ile razy hashowane sa hasła. A wtedy to ma już z górki. Natomiast w przypadku gdy ma tylko cudze hashe i nie wie ile razy została wykonana funkcja md5() może mieć już większe problemy. Ten post edytował Kicok 21.10.2008, 11:15:26 -------------------- "Sumienie mam czyste, bo nieużywane."
|
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 24.04.2024 - 10:35 |