Forum PHP.pl

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.

Ten post edytował -=Peter=- 19.07.2010, 18:04:03

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.