Witam wszystkich, czytałem kilka tematów że nie da się lub jest bardzo ciężko rozkodować hasła md5. Ja mam prosty sposób którego chyba nie mogę zdradzić, ale żeby wam to udowodnić poproszę o wasze jakieś hasła w md5 i zobaczymy czy działa. Mogę przyznać że sposób nie zawsze znajdzie hasło, ale w większości znajduje.

I dodam że waszych haseł nigdzie nie wykorzystam ani nie podam więc możecie być spokojni.

Taak?
Ja znam lepszy, i każdy sam może sprawdzić.
http://anqel.pl/narzedzia/md5/md5search.php

Widać, kto czyta przyklejone wątki. Była gdzieś dyskusja z pogranicza kryptoanalizy i matematyki, aby obalić mity o MD5.

Do autora: ciąg nie musi być ten sam; wystarczy, że ktoś uzyska generujący identycznego hasha.


Stare przysłowie adminów mówi: traktuj hasło jak szczoteczke do zębów - nie dawaj go nikomu i zmieniaj raz na 3 miesiące.

Możesz śmiało wstawić na forum a ja Ci powiem czy to jest to hasło - brutal force troszkę by Ci zajął.
Miłej zabawy.

Przy rainbow tables? Kwestia paru godzin, z tego co mi wiadomo.

Rainbow tables +użycie GPU (jak przy łamaniu Wi-Fi) i po MD5...

955e93d12df63666164b7d20029deaa1

Autor widać słabo czytał temat o md5, a o tęczowych tablicach pewnie nie słyszał, albo słyszał ale nie wie gdzie dzwonią Brute force a sobie pogeneruje lata zanim znajdzie prawidłowy hasło a ktoś mu napisze... "Sorry, to nie moje hasło", bo przecież nie musi autorowi tematu powiedzieć "Chłopie... Takie ja mam inne m hasło główne, ale dodatkowo je solę, co zmienia kompletnie ciąg idący do funkcji hashującej"

I jak widać autor nie rozumie pojęcia kodowania lub upraszcza je. Hash nie jest możliwy do odkodowania z samej definicji hasha. To algorytm jednostronny. Nie jest możliwe odczytanie hasła z hasha. Można jedynie wygenerować miliardy hashy i szukać tego pokrywającego się. A by było śmieszniej, kilka haseł może mieć identyczny hash i znowu kupa

Właśnie to nie jest wcale takie śmieszne, jeżeli hash dla dwóch i więcej stringów będzie się pokrywał to nie musisz znać dokładnie hasła użytkownika, możesz w polu hasła wpisać ciąg, który wygeneruje identyczny hash.

Logowania pisane na zasadzie:

[PHP] pobierz, plaintext 
$x = mysql_query('SELECT id from users where login = 'cos' and haslo = "'.md5($_POST['haslo']).'" LIMIT 1');
[PHP] pobierz, plaintext 

NIE SĄ odporne na kolizję w md5.

Dlatego można ograniczyć długość hasła do np. 16 znaków, wtedy ryzyko kolizji jest bardzo małe, bo nie będzie można wpisać np. 104 znakowego ciągu znaków, który ma to samo md5 co moje posolone 10 znakowe hasło

Istnieje możliwość wygenerowania 1,15e+106 kombinacji z 16-sto znakowego pola do hasła - to tak pi razy drzwi dwa razy więcej niż ilość wszystkich kombinacji md5 - prawdopodobieństwo znalezienia kolizji na pewno spada, ale nadal istnieje.

No chyba, że z jakiegoś powodu algorytmy wyszukiwania kolizji muszą operować na zestawie znaków a-z0-9, a nie całej palecie Unicode - nie wiem, nie znam ich.

I dlatego Crozin ja się śmieję, gdy ktoś używa podwójnego md5 czy podobnych "utrudnień". Nie rozumie idei stojących za hashami. Prawda jest taka, że najlepsze byłoby odejście od powszechnych algorytmów i tworzenie własnych. Włamujący się często sięgają do powszechnie stosowanych algorytmów i pod ich kątem próbują złapać byka za rogi. Jeśli na stronie zastosowano by własny algorytm, wtedy szansa wpadki drastycznie maleje. Stąd też skuteczność soli jest taka. Podajesz hasło z niewiadomym prefixem, suffixem lub obydwoma. Dopóki włamywacz nie ma do nich dostępu ma utrudnioną szansę na dopasowanie. Może nawet znać hash i oryginalne nie zakodowane hasło a i tak nie zna tych dodatkowych, więc nie napisze algorytmu, który wygeneruje mu tęczowe tablice. Gorzej, jeśli ma te sole, bo wtedy sprawa się radykalnie upraszcza. No ale kto się tematem bezpieczeństwa interesuje, ten akurat wie, że próba każda zabezpieczenia niemal 100% wiązała by się niemal z paranoidalnym podejściem do przechowywania wszystkiego. Sole, hashe w różnej formie, na różnych serwerach, w protokołach SSL i po różnych bazach porozrzucane by nabrało to cech jako takiego bezpieczeństwa.

@thek: Własne rozwiązania są dobre, jeśli pilnie strzeżone. Atak 'standardowy' się nie powiedzie, trzeba napisać dedykowany. Oczywiście pisanie własnych funkcji skrótu mija się z celem, ale można tworzyć własne 'forki', łączyć md5 z sha1 i brać np pierwszych X znaków z wyniku jednej i kolejnych Y znaków z drugiej etc...

Odnośnie Twoich przykładów z solą, prefixem, suffixem - mają zastosowanie jedynie przy łamaniu hasła, czyli próbie jego odgadnięcia w formie takiej, aby można było dokonać 'zwykłego' logowania. Natomiast w przypadku tęczowych to nie ma znaczenia, bo i tak się dobiera taki ciąg, który wygeneruje taki sam hash. Zatem wszelkie dodatki nic nie utrudnią przy takich technikach łamania. (Chyba, że miałeś na myśli prefixy dodawane do finanlego hasha)

A jak używam wszędzie pseudolosowych, tasiemcowatych 20-znakowych potworów, to co? Nie widziałem jeszcze większej głupoty niż ograniczanie komuś na siłę w dół wymagań co do haseł. Zuo!


To ktoś jeszcze używa md5 do hashowania haseł w aplikacjach? Mało to innych, lepszych algorytmów? hash - zobacz, ile ich PHP udostępnia.

Tak BTW: Temat: podwojne hashowanie hasel

Nie ma sensu pisać n-ty raz czegoś, co było już omówione.

Jakbym napisał "hash", zamiast "md5" to poczułbyś się lepiej? Moje zdanie nie odnosiło się tylko do jednego algorytmu hashowania, bo każdy skrót wiadomości ma ograniczoną długość przez co funkcja tworząca taki skrót nie jest funkcją różnowartościową. Jeśli ograniczymy długość hasła (dziedziny) to w tym przedziale funkcja będzie miała taką samą wartość dla mniejszej ilości różnych argumentów wejściowych - może być też taki przypadek że w tej dziedzinie funkcja będzie różnowartościowa.


Nie lubię takich kontrargumentów, ale na np. allegro i systemie internetowym mojego banku takowe ograniczenia mają (odpowiednio na 20 oraz 16 znaków). Nie żebym swoje zdanie opierał na tym, że tak robią inni to ja też, bo do tego zdania doszedłem drogą logicznej dedukcji, a to że przed momentem losowo sprawdzone dwa serwisy, w których teoretycznie bezpieczeństwo powinno być na pierwszym miejscu, takie coś stosują, tylko utwierdza mnie w tym przekonaniu Pewnie na tym forum również hasło ma z góry ograniczony limit długości, nie sprawdzałem.

No tak, ale są algorytmy, dla których znalezienie kolizji trwa latami na współczesnych komputerach. A MD5/SHA1 jest np. namiastką Whirlpoola pod tym względem.


Muchy lubią g... Miliony nie mogą się mylić! Bez urazy, ale opierając swoje dedukcje na argumentach, że bo alleniegro tego używa raczej tylko miejsce w bazie na posty zapychamy.


No musi mieć, trzeba jakoś przeciwdziałać DoS-om.

I tutaj nie do końca masz rację vokiel. Przyjmując, że znasz hash, możesz odczytać z tęczowych tablic ciągi wejściowe. Jest ich ileś tam i miałbyś rację, że to koniec gdyby ktoś roił tylko md5($haslo). Jeśli zrobi md5($sol.$haslo.$sol2) to powiedz mi skąd "haxor" ma wiedzieć jaki naprawdę był ciąg wejściowy? Skoro może z formularza wbijać tylko część oznaczoną jako $haslo to skąd będzie wiedział jakie stringi kryją się pod $sol i $sol2? Z każdego hasha ma X odczytanych ciągów wejściowych i z nich musi uzyskać to, co kryje się pod $sol i $sol2, by móc dopiero szukać tego, co może wpisać pod $haslo by mu w formularzu wyszedł pokrywający się hash. Bo przecież zaistnienie kolizji z ślepym wstawianiem losowych ciągów, gdy wiemy, że sól istnieje jest równie prawdopodobne z jak i bez użycia tęczowych tablic. Tutaj znajomość hasha po prostu nam nic nie daje, bo nie znamy części ciągu, który go nam utworzy. I tak skończy się na ataku brute-force

@erix wiem, że umiesz czytać ze zrozumieniem, więc jeszcze raz przeczytaj cytowany przez Ciebie fragment mojego postu. Wyraźnie napisałem, że sprawdziłem dwa losowe serwisy po napisaniu przeze mnie pierwszego posta w tym temacie, więc Twoje słowa raczej są nietrafione.

Pozatym nie sądzę, że programiści pracujący w allegro oraz programiści którzy napisali system banku, w którym mam konto, są głupimi muchami

Przytocz mi jakieś obiektywne argumenty, bo na razie tylko wymijasz z dyskusji, a żadnych dowodzeń nie ma. Fakt, jestem bardziej humanistą, ale to nie zmienia faktu, że kojarzenie tego, co już wiemy powinno prowadzić do oczywistości. To że wielkie serwisy, które odwiedzasz, stosują, to wcale nie jest argument. Owczy pęd? To też można by było przyrównać do Twojego toku rozumowania. Bo z tego co wnioskuję na podstawie posiadanej przeze mnie niewiedzy, to jakoś innego logicznego wytłumaczenia nie jestem w stanie znaleźć.


Zdziwiłbyś się. Miałem okazję widzieć kod pewnej aplikacji, która wykonuje pewne newralgiczne obliczenia i naprawdę się cieszę, że nie wszyscy są świadomi, jak działają...

Więc jak, doczekam się jakichś podstaw, na których opierasz swoją dedukcję, czy nadal będziemy używać argumentu bo X i Y tego używają? Jeśli nie, darujmy sobie dyskusję, bo nie ma sensu.

Jeden z argumentów który wcześniej podałem:


Reszty nie mam zamiaru objaśniać, bo nawet nie raczysz przeczytać o czym wcześniej pisałem, a jedynie doczepiłeś się mało istotnych szczegółów które Ci się w oczy rzuciły.

To jak wytłumaczysz fakt, że nawet dla kilkugigabajtowych plików jest ciężko osiągnąć jednakowe hashe?


Przeczytałem, ale patrz wyżej.

Prawdopodobieństwo, że dwa losowe ciągi wejściowe będą mieć ten sam hash jest rzędu 1/(n^k), gdzie n - ilość znaków wykorzystywanych w hashu, k - długość hasha. Przykładowo dla md5 () to będzie 1/(16^32). Jest to spore uproszczenie, bo to prawdopodobieństwo zależy też od różnicy długości tych ciągów wejściowych, aczkolwiek to już kwestia algorytmu hashującego.

Hmm, wg przytoczonych przez Ciebie wzorów, im dłuższe hasło, tym mniejsze prawdopodobieństwo...?

1/(16^32) > 1/(17^32)

Wystarczy zmienić algorytm haszowania na SHA256, SHA386, SHA512, itd... i to już jest praktycznie niemożliwe do wyszukania.
Zmniejsza też prawdopodobieństwo kolizji niemalże do zera.

Ja polecam używanie niestandardowych funkcji hashujących oraz dodawanie różnych soli tj. inna sól dla każdego użytkownika.


Jeśli chodzi o Allegro. Jeśli chce się przypomnieć hasło wysyłają je w normalnej jawnej postaci na e-mail. Więc, albo trzymają w bazie hasła niezakodowane, albo zakodowane algorytmem dwustronnym(może teraz się coś zmieniło?)? Przepraszam ale to jest moim zdaniem kretyńskie rozwiązanie... Podobnie jest w o2 i wp. Ostatnio nawet ktoś wykradł loginy i hasła. Raczej ciężko jest rozpracować kilka tysięcy haseł. No, żechyba ktoś słownikowo rozgryzł tylko te najprostsze co jednak i tak pokazuje, że wielkie portale nie zawsze muszą się znać na tym co robią...

Masz wystarczającą wiedzę, doświadczenie, zasoby ludzkie i finansowe żeby opracować, zaimplementować i przetestować nowy algorytm haszujący? nie uważasz że to trochę bez sensu (i co najważniejsze) mało prawdopodobne, że odniesiesz sukces?

Gdyby była potrzeba wymyślania nowych metod haszowania (lub wymyślanie ich przyniosłoby jakiekolwiek korzyści) to byś widział co jakiś czas jakiś nowy algorytm, a tak to cały przemysł informatyczny z powodzeniem używa algorytmów wymyślonych kilkadziesiąt lat temu i przetestowanych pod kątem wielu scenariuszy i w wielu środowiskach.

http://www.hcsl.pl/2010/07/nieskomplikowan...dnoczesnie.html

...


A co tu testować, jeśli został już przetestowany i algorytmy są powszechnie wykorzystywane, np. whirlpool, sha512, ripemd160?

Co do prawdopodobieństwa sukcesu - spotkałem się ze skryptami, w których warstwa autoryzacyjna zapisuje hash w jednym z losowo wybranych algorytmów. Potem, przy autoryzacji, jeśli hash z prawidłowym hasłem jest niezgodny, następuje sprawdzanie kolejnego z listy. Jeśli cała lista zawiedzie - brak auth. Do tego zakodowana aplikacja i choćby ktoś rozpracował algorytm dla jednego hasła, to dla reszty będzie miał problem.

@nasty: Może źle się wyraziłem. Pisząc niestandardowy nie miałem na myśli własny... Ważne aby unikać md5, sha1 bo one są najbardziej popularne. Szczególnie md5 ma pokaźną bazę hashy, oprogramowania itd. Sha256, sha386, sha512 są jak najbardziej w porządku.

Mowa była o niestandardowych algorytmach. Te wymienione są już opracowane: http://en.wikipedia.org/wiki/Template:Crypto_hash



I uważasz, że to jest mądre rozwiązanie?


@up: Okey, jeśli tak to masz rację źlę Cię zrozumiałem.

Owszem. Może nieco wolniejsze niż jeden algorytm, ale... Miałem okazję poznać coś takiego na podstawie pewnego sporego skryptu, nazwy, niestety, nie mogę podać.

Przy współczesnych dodatkowych rejestrach procesorów przeznaczonych wyłącznie funkcjom kryptograficznym narzut jest niewielki.

Zawsze tak było - albo wydajność, albo bezpieczeństwo.

Ok to może mój punkt widzenia:

Takie rozwiązanie jest idiotyczne. bo:

1. Tak jak wspomniałeś: działa wolno.
2. Algorytmy hashujące są projektowane w taki sposób, żeby nie miały (albo jak już to minimalnie) kolizji.. ale tylko w przypadku działania tego samego algorytmu. W przypadku działania takiego dziwactwa to nie możesz tego zapewnić.
3. Nie możesz sprawdzić czy dane jakie masz w bazie są poprawne, trudno też dobrze zaprojektować bazę pod kątem wielkości pola w którym trzymane są hasła (chyba, że używasz baz nierelacyjnych).
3. Jakbyś chciał zrobić specyfikację dla tego systemu (np. sprzedajesz firmę, robisz integrację z czymś innym czy np. dla potomnych) to nie masz jak to opisać w dokumentacji w normalny sposób, albo przynajmniej taki, żebyś nie został wyśmiany.
4. To jest kompletnie bez sensu i nie daję żadnego dodatkowego bezpieczeństwa.

Dużo lepszym rozwiązaniem byłoby użycie jednego algorytmu hashowania + sól i to wszystko.



1. Don't think, RAM is cheap. Baaardzo zła wymówka żeby nie myśleć jak się produkuję oprogramowanie.
2a. Po pierwsze rejestry nie liczą, są one tylko pamięcą.
2b. Wcale tak nie jest. Funkcje haszujące nie różnią się niczym od innych funkcji i są przetwarzane tak samo jak inne.
2c. AES (jeśli nagooglowałeś) to nie funkcja haszująca.
3. Wcale tak nie jest, że albo wydajność albo bezpieczeństwo. Jedno nie koliduję w żaden sposób z drugim.

IMHO szyfrowanie haseł w bazie szyfrem dwustronnym (ten przykład z allegro) to totalna pomyłka. Po co komuś jego stare hasło, skoro można wygenerować nowe i je zmienić. Poza tym sprowadza się to do jednego hasła dla wszystkich użytkowników.

Odnośnie wyboru różnych funkcji skrótu to w zasadzie nic nam nie daje. Przejście po kolei przez 5 algorytmów zrobi narzut większy niż wykorzystanie w każdym przypadku jednej funkcji (nawet wybierając tą najmocniejszą-najwolniejszą). Nie zwiększa też bezpieczeństwa. Różnicuje je, bo część haseł będzie szyfrowana jednym mocniejszym algorytmem, część innym słabszym.

Różnicę w długości hashy można obejść ustalając taką jaką tworzy najkrótszy algorytm, a ucinając do danej długości inne.

Ciekawym rozwiązaniem może być ingerowanie w wynik działania funkcji skrótu. Przykładowo tworzymy hash z hasła + salt + login + data rejestracji, wynikowy hash dzielimy na części i np zamieniamy kolejność tak wydzielonych bloków. Można też dodawać coś swojego tak, aby np wynikowy hash z jednej funkcji wyglądał jakby był utworzony przez inną. Takie zmylenie przeciwnika

Hmm, w takim razie wytłumacz mi zasadność takich działań w przypadku oprogramowania do szyfrowania dysków.


Niby dlaczego? W ten sposób minimalizuję ryzyko ew. ataku tęczowych tablic w przypadku uzyskania całej bazy.


Dlaczego nie mogę? Wiem, którego użytkownika szukam, wyciągam jego hash i sprawdzam pod kątem wszystkich wybranych funkcji hashujących do momentu trafienia. A jeśli chodzi o wielkość pola - hmm, tu można polemizować.


Każde rozwiązanie bazujace na istniejących algorytmach da się opisać w czytelny i konkretny sposób. Nadal nie rozumiem Twojego "zarzutu".


Ech, a czytasz moje posty w całości, czy tylko po łebkach? Poza tym, bo mi się wydaje bez sensu nie jest argumentem.

Wspomniałem o stosowaniu w oprogramowaniu podobnego rozwiązania: http://www.freeotfe.org/docs/Main/FAQ.htm#bm.


Też nie znoszę tej wymówki, ale teraz popadamy w skrajności i offtopa.


Ok, użyłem złego określenia. Nie podejrzewałem, że będę łapany za słówka, nie będę odgrażał się tym samym.


Owszem, szyfrowanie symetryczne. Jednak większość algorytmów - w mniejszym lub większym stopniu - korzysta z jakichś funkcji kontroli sum. Poza tym, procesory są już od jakiegoś czasu wyposażane w odpowiednie ROZSZERZENIA zapewniające sprzętową akcelerację podstawowych operacji kryptograficznych: http://marc.info/?l=openssl-dev&m=1085...1323715&w=2


Hmm, to posiadamy jakieś sprzeczne informacje. Dlaczego, w takim razie, hashujemy hasła w bazach, będąc świadomym że hashowanie jest bardziej czasochłonne niż zapisanie czystego hasła. Bezpieczeństwo kosztem zmniejszonej wydajności. Więc?

Jak napisal ropozlop, hash + salt i po temacie.

Taki np Intel i5 ma wbudowaną obsługę AES'a, i tak u mnie dzisiaj rano, TrueCrypt 7 pokazał taki wynik benchmarku:

erix, Czy ty chcesz prowadzić dyskusję i dojść do konstruktywnych wniosków czy jak nie wiadomo co upierać się przy swoim byle udowodnić, że masz rację?

Hmmm... Wspomniany tu przez erix-a algorytm ma moim zdaniem jedną słabość... Hashe muszą być odpowiednio długie by wyeliminować możliwość kolizji i jednocześnie wszystkie muszą mieć identyczną jego długość by nie można było określić, który został użyty. No chyba, że założymy losową długość klucza i każdy będzie sprawdzany jakby to był inny przypadek. Ale nawet wtedy jest możliwość (minimalna, ale zawsze) pokrycia się wartości wynikowych dwóch przypadków. Co wtedy? Jak algorytm określi, który jest prawidłowy? Zacznie przykładowo analizować, czy zaszyfrowana partycja po odszyfrowaniu ma prawidłową strukturę? O ile do samego algorytmu i sprawdzania iluś hashy/szyfrów nie mam się co czepić, bo faktycznie jest to rozwiązanie bezpieczniejsze (zmienne metody i długości), to nie może ono być stosowane szeroko, bo i nie zawsze będzie dobre.

Co do długości pola to powiedz czym od strony wydajności bazy będzie ustawienie zmiennego varchara o długości największego klucza a czym stałej długości? Char jest szybszy - to prawda, ale przecież logowania i weryfikacji nie robimy temu samemu userowi co 5 sekund... Poza tym unikalny nie jest sam hash hasła. Unikalna jest kombinacja loginu i tegoż hasha. Jeśli ktoś dorwie bazę, to nawet gdyby serwis nie solił haseł, zdoła jedynie wycinek bazy odczytać, który by określonej metody się trzymał. By "padły" wszystkie musiałby znać metody użyte w serwisie i liczyć, że hasła nie są solone.

~thek: nie ma możliwości całkowitego wyeliminowania kolizji w md5, można tylko zmniejszać - z różnym skutkiem - prawdopodobieństwo jej wystąpienia.

Darko... Ale my tu nie tylko o md5. Nie tylko md5 czy sha istnieją Temat już jakiś czas temu przeszedł w znacznie szersze zagadnienie, ogólnie bezpieczeństwa, celowości i wydajności stosowania szyfrów oraz hashy.

ok, thek w takim razie: nie ma możliwości całkowitego wyeliminowania kolizji w algorytmach/funkcjach haszujących, można tylko zmniejszać - z różnym skutkiem - prawdopodobieństwo jej wystąpienia.

Owszem. Tylko nie widzę sensu prowadzenia jej z Tobą, skoro jesteś zamknięty na moje argumenty i uparcie siedzisz przy własnych. Przedstawiłem swoje, uważam że zasadne, a Ty tylko skwitowałeś bez odniesienia. Temat będzie zawsze na czasie, a nic się wielkiego nie stanie, jeśli dojdziemy do jakichś nowych wniosków.

I porównania do osła sobie daruj, bo to świadczy o porównującym.


Liczyłem, że ktoś wreszcie na to wpadnie.

Poza tym, nawet jeśli istniałoby prawdopodobieństwo przeprowadzenia ataku DDoS poprzez wielokrotne logowanie - wystarczy ograniczać liczbę nieudanych logowań per konto i/lub IP.