@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

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

Mógłbyś podać jakieś źródło?

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.

Porównanie trzech metod przechowywania haseł jako hashe md5:

1. md5( HASLO )

[PHP] pobierz, plaintext 
<?php
 
    $login = mysql_real_escape_string( $_POST['login'] );
    $haslo = $_POST['haslo'];
 
    $haslo = md5( $haslo );
 
    $result = mysql_query( "SELECT * FROM users WHERE login = '$login' AND haslo = '$haslo'" ) or die( mysql_error() );
    if( mysql_num_rows( $result ) )
    {
        // ZALOGOWANY
    }
 
?>
[PHP] pobierz, plaintext 

2. md5( HASLO + SÓL )

[PHP] pobierz, plaintext 
<?php
 
    define( 'SALT', '#@r23T@f23NJOąąąĆóŁd;'[:""{:ffs+SD:+@wD#~`ds2' );
 
 
    $login = mysql_real_escape_string( $_POST['login'] );
    $haslo = $_POST['haslo'];
 
    $haslo = md5( $haslo . SALT );
 
    $result = mysql_query( "SELECT * FROM users WHERE login = '$login' AND haslo = '$haslo'" ) or die( mysql_error() );
    if( mysql_num_rows( $result ) )
    {
        // ZALOGOWANY
    }
 
?>
[PHP] pobierz, plaintext 

3. md5( md5( HASLO ) )

[PHP] pobierz, plaintext 
<?php
 
    $login = mysql_real_escape_string( $_POST['login'] );
    $haslo = $_POST['haslo'];
 
    $haslo = md5( md5( $haslo ) );
 
    $result = mysql_query( "SELECT * FROM users WHERE login = '$login' AND haslo = '$haslo'" ) or die( mysql_error() );
    if( mysql_num_rows( $result ) )
    {
        // ZALOGOWANY
    }
 
?>
[PHP] pobierz, plaintext 

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:


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ó&#0GHG: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:



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.

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?

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

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

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.



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 )?

Brute force wykonuje sie zazwyczaj na aplikacji, wiec aplikacja bedzie przepuszczala to przez podwojne hashowanie

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.

hej. zainteresowała mnie ta dyskusja.
mam jedno pytanie, laika w tych sprawach: jak się ma stosowanie metody BF do złamania hasła, jeżeli dodamy w skrypcie ograniczenie max. ilości logowań oraz captchę? czy będzie to miało wpływ jakiś na tą metodę ?

Źle zrobioną captchę łatwo obejść, na dobrą też są już znane sposoby. Ograniczenie ilości logowań jest dobrym pomysłem, o ile oprzemy je o coś, co nie jest łatwo zmienić między dwoma żądaniami (np. adres IP), a nie np. ciastka sesji . Jednak da to efekt tylko, jeśli przeprowadzać będziemy atak na całą witrynę WWW. Jeśli ktoś wejdzie w posiadanie kopii bazy danych, albo samej zawartości tabelki użytkowników (kradzież, włamania, błędy zabezpieczeń), nic nam to nie da, ponieważ atakujący może sobie spokojnie operować na własnym komputerze na gołych danych .

Ja polecam mieszanie hashów - np. md5 + sha256: najpierw shashować za pomocą md5, wyciąć np. pierwsze 7 znaków z powstałego hasha i shashować je metodą sha256, po czym jakoś skleić te ciągi - od 8 znaku do końca z tego z md5, i cały sha256. Można jeszcze te ciągi jakoś pomieszać - np. sha256 przeciąć na pół (lub nierówne części), i jakoś pomieszać powstałe części z tym ciągiem z md5. Biorąc pod uwagę fakt, że każdy programista tym sposobem ustawi sobie inne kombinacje, starsznie trudnym zadaniem byłoby złamanie takiego szyfu

@Apocalyptiq:
Strasznie trudne byłoby odkrycie prawidzwego ciągu wejściowego, natomiast samo złamanie zabezpieczenia byłoby dokładnie takie samo jak w przypadku jednokrotnego haszowania MD5. Ponadto zasugerowana przez ciebie metoda będzie baaardzo obciążająca.

Ja wiem czy duże obciążenie serwera? Przeprowadziłem mały test:

Czas wygenerowania takiego czegoś - około 0,01s

Dla porównania:
http://kohanaphp.com/home

Ale ten test przeprowadziłem dla 100x hashowania - a mało mozliwe, że w tej samej sekundzie będzie chciało nam się zalogować/zarejestrować 100 użytkowników A i hasła wprowadzane przez użytkowników są znacznie prostsze niż ciąg generowny przez uniqid, który zastosowałem w teście.

Ale tak w ogóle, przed czym ma chronić to hashowanie?
Hash osoba trzecia może zdobyć albo przez cookies, jeżeli istnieje na naszej stronie możliwość autologowania, i własnie hasha zapisujemy w ciastkach (np. ktoś w kawiarencie logując się na nasz serwis wybrał, żeby go zapamiętało - ktoś inny siada na tym kompie i wyjmuje hasha z ciastek, no ale w takim przypadku i tak ma dostęp do danego konta ), albo jakoś je wychwycić z bazy - ale jeżeli stosujemy np. PDO i bindujemy wszystkie zmienne, które wprowadza użytkownik (m.in. pochodzące z formularzy), to np. sql injection jest praktycznie jest niemożliwe. Więc po co te hashe?
Chyba że zrobilibyśmy tak, że w profilu, jeżeli ktoś chciałby zmienić hasło/e-mail - wymagane będzie wpisanie aktualnego hasła, wtedy ktoś, kto dostał się na czyjeś konto, a nie zna hasła, danego konta nie przechwyci (nie zmieni hasła). A czy istnieje możliwość edytowania/dodawania sobie w przeglądarce ciastek? Bo jeżeli tak, to możnaby sobie hash z kawiarenki skopiować, w domu utworzyć odpowiednie ciastka z tym hashem, i wtedy działałoby autologowanie.

Żeby hash hasła trzymać w cookie... trzeba być naprawdę geniuszem.

A po co te hashe? Chociażby po to byś Ty przeglądając bazę danych nie znał haseł użytkowników...

A ja to robie inaczej po 10 nie powodzonych probach logowania(mowa o wszystkich nie 10 pod rzad) konto zostaje zbanowane na kilka minut i tyle i jak ktos chce moze sobie robic brute-force a hasla hashuje samym md5() i tyle.

A co w przypadku, gdy ktoś złośliwie będzie udawał próby włamania na czyjeś konto i w ten sposób będzie mu je banował na kilka minut? Tego chyba nie wziąłeś pod uwagę...

Mowi sie trudno cos za cos zreszta nie jest to portal taki jak php.pl wiec no problem a poki ktos nie sproboje to o tym nie wie.

A znasz jakiś inny dobry sposób na automatyczne logowanie?

człowiek się stara pisze, a nikt tego później nie czyta :-(
http://www.beldzio.com/autologowanie

A żebyś wiedział... opór materii jest niesamowity.

Apocalyptiq -> no i co Ci przychodzi z takiego cudacznego zabezpieczenia? Skoro zdobędę dostęp do bazy, prawdopodobnie kwestią czasu jest także uzyskanie dostępu do kodu źródłowego. Jak ty się bawisz w sklejanie, mi wystarczy prosta nakładka na moją bazę haseł opracowana na podstawie Twojego kodu, by Twoje dodatki ominąć i po kłopocie. Era tajnej kryptografii skończyła się 30 lat temu. Era amatorskiej kryptografii jeszcze wcześniej. Nad funkcjami mieszającymi siedzą najlepsi matematycy świata. Szansa, że na chybił trafił ktoś stworzy coś lepszego, jest bliska zeru - w zdecydowanej większości przypadków tylko pogarszacie sprawę.

http://www.zyxist.com/pokaz.php/wielokrotne_haszowanie - polecam do przeczytania

A następną osobę, która w tym temacie będzie chciała wyskoczyć z kolejnym "genialnym" pomysłem na podwójne zahaszowanie haseł czy ich pomieszanie, proszę, żeby przeczytała kilka powyższych postów.

Czyli równie dobrze można nie kodować haseł ;-) bo zakładając że hacker dostanie i bazę i źródło kodowanie mieszanie md5 i sha1 + sól etc to i tak złamie hasło.

A to wiąże się z koniecznością przesłania tego hasła - czyli kolejna potencjalna bramka do haseł.Tutaj o hashowaniu mowa, nie kodowaniu. Zdobycie surowych haseł to dostępn do wszystkich odrazu, zdobycie listy hashów wiąże się z koniecznością "rozszyfrowania" (najczęściej BF) każdego z osobna co może zająć od kilkunastu minut do kilkudziesięciu godzin. Razy np. 10 000 (przykładowa ilość użytkowników) - i może Ci wyjść wynik kilku lat potrzebnych do zdobycia pełnej listy surowych haseł - ale sukcesu nigdy nie możesz być pewien.

Już napisałem "pare" postów wyżej że są 3 przypadki "ataku" i hashowanie ma sens tylko w 2 z nich. Natomiast sam kiedyś wszedłem w posiadanie tabelki users pewnego serwisu (przez przypadek) pomimo ze nie mogłem/nie chciałem mieć dostępu do kodu źródłowego.
Ale z czystej ciekawości puściłem słownik + md5 na hasła z 400 userów "odgadłem" około 40 z czego pięć haseł to było "kasia" albo coś w tym stylu ile z tych haseł było tymi samymi hasłami co do poczty nie wiem :] ale od tamtej pory nikt nie wmówi mi że dodawanie soli do hasła jest bez sensu. Ostatnio naszła mnie taka myśl :] ... hasło każdy z userów może dać sobie dupa13 ale login musi być unikalny .... oczywiście metody typu md5($login.$haslo) są pewnie wszystkim znane i szeroko stosowane ale może roll(md5(haslo), strlen($login)). itp itd. możliwości jest wiele.

n-hashowanie nie zwiększa możliwości wygenerowania kolizji n razy tylko do n-tej!
Oznacznmy ilość ciągów o długości 32 znaków generujących ten sam hash przez m.
Dla pierwszego stopnia m ciągów o długości 32 znaków.
Dla każdego ciągu o tym samym hashu pierwszego stopnia istnieje kolejnych m ciągów o tym hashu.
Itd.

Czyli dostajemy ładne drzewko, w którego ostatnim stopniu mamy m^n 32 bajtowych ciągów które wygenerują żądany hash po n-krotnym shashowaniu.

Ktoś napisze że szukanie tych 32-bajtowych ciągów zajmie wieczność, jednak każdy z nich ma prawdopodobnie ileśtam krótszych kolizji.

Tak więc zamiast szukać kolizji z jednym hashem, haker będzie szukał kolizji z m^n hashami.

Co prawda założyłem że kolizyjne hashe się nie powtarzają w ramach jednego stopnia, oraz że dla każdego hasha istnieje tyle samo kolizji o długości =32. O ile drugie założenie się uśredni, o tyle pierwsze nieco zawyża wynik.

Uważam że o wiele sensowniejszym rozwiązaniem jest używanie soli, które uniemożliwi używanie rainbow tables, i nie odsłoni skryptu na ataki brute-force. Ponadto, lepiej używać algorytmów mocniejszych niż md5. Jeżeli hosting nie oferuje hashowania sha1, można takie wkleić w postaci kodu php, lub zrzucić na bazę danych. Jeżeli ta jest w sieci wewnętrznej względem serwera php, szanse podsłuchania przesyłania hasła od klienta do php, będą takie same jak z php do SQL (chyba że ta pierwsza idze po SSL, ale jak jest SSL to rzadko kiedy nie ma sha1).

1. Nie ma sensu wielokrotne haszowanie ani używanie nie wiadomo jakich algorytmów w tym celu
2. Ma sens natomiast solenie, nawet najprostsze, na wypadek, gdyby ktoś przechwycił hasz i chciał skorzytać ze słownika

- ja już widziałem nie tylko hasz, ale i całe hasła + loginy do kompletu - wiele widziałem, np. system logowania w JS, który trzymał hasła w kodzie strony a miał jeszcze taką cudowną właściwość, że wystarczyło wyłączyć obsługę JS, by być zalogowanym.

- mamy XXI wiek, prawie każda przeglądarka oferuje zapamiętanie loginu oraz hasła.

Nie wiem czy została podana jedna - chyba najważniejsza własność metody sh1 i odciacie losowych 4 znakow - oczywiscie stałych dla każdego hasła

Zwiększa się ryzyko że hasło się powtórzy to prawda - ale jeżeli ktoś wyciągnie potem hashe z naszej bazy - to mu nic szczerze nie dadza, nawet jeżeli będzie wiedział które liczby wycielismy i czym hashujemy, to musi powstawiać losowe zmienne do hasha, a potem b-f dojść do wszystkich kombinacji tych hashy (dla przykładu podam, że hash wyglądał by wtedy np tak. [$j]E[$i]6#[$k]w9a3^[$g] - myślę, że niewielu osobą by się to chciało, kiedy możliwość że trafi na hasło osoby która użyła tego samego loginu i hasła jest niewielka (np dodanie przy rejestracji informacji że musi zostać podany w haśle jeden znak specjalny, inaczej nie przejmuje rejestracji - to jest chyba najlepsza metoda - aby wymusić na userze podanie skomplikowanego hasła.)

Ave

ciekawy temat i chetnie sie tu wypowiem. i chociaz nie znam sie na tym najlepiej, to chyba warto odswiezyc temat

po1 trzeba rozgraniczyc pod jakim katem rozstrzygamy zabezpieczenia hasla
przede wszystkim uwazam, ze nalezy uswiadamiac uzytkownikom jak wazne jest tworzenie skomplikowanych hasel na poziomie odpowiednim do waznosci odpowiadajacym tym haslom kont. i jak ktos wczesniej juz wspomnial mnostwo osob posiada banalnie proste slowa lub imiona jako hasla, o dlugosci zazwyczaj 5, 6 znakow, rzadziej 4 lub 7. malo tego uzywa jednego hasla do wszystkiego [sic!] wiem to z doswiadczenia, bo od lata pomagam ludziom przy prostych sprawach zwiazanych z kompem i jak oni zakladaja nowe konta i pisze 'podaj email: ____ haslo: ____' to podadza haslo do wlasnego mejla.... zenujace, ale prawdziwe. dlatego jeszcze raz powtorze jak wazne jest wpajanie ludziom tej podstawowej wiedzy dot. bezpieczenstwa kont.
uwazam, ze podstawy to: minimalna dlugosc hasla, nie zawieranie loginu, zawierajace cyfry, duze litery oraz inne znaki "£$%^&* w roznych miejscach, a nie np kasia123 etc i chyba lepiej zapisac sobie na kartce wazne haslo i trzymac gdzies w domu, niz wybrac proste haslo i je pamietac

druga rzecz to zabezpieczenie dostepu z poziomu aplikacji.
tutaj zabezpiecza sie haslo uzytkownika, bo jesli ktos uzyskal dostep do mechanizmu szyfrujacego, to jesli jest on jednostronny, uwazam, ze standardem powinno byc dodawanie soli indywidualnej dla kazdego uzytkownika, bazujacego na jego danych. bardzo moze to utrudnic lub wrecz uniemozliwic dostep do prawdziwego hasla.

wielkrotne hashowanie? chociaz rowniez nie zaglebiam sie w tajniki algorytmow hashujacych wydaje mi sie, ze wielokrotne hashowanie zwieksza mozliwosci kolizji. w jakim stopniu, to nie bede zgadywal, bo to sie mija z celem. jesli ktos zdobedzie hash, to moze uzyc bazy, ktore zawieraja 2 czy 3 krotne hashe. i to sie mija z celem, bo naprawde lepiej jest uzyc soli. moze sie myle, ale chyba nie ma zadnych minusow ich uzywania?
mamy oczywiscie ograniczona liczbe hashow. przeprowadzajac wielokrotne [nieskonczone] hashowania moga doprowadzic nas chyba tylko do zapetlenia - po x hashowaniach otrzymamy taki sam hash jaki mielismy wczesniej. podejrzewam, ze mozna czesc [1/4? 1/8?] hashy odrzucic, ktorych zaden ciag znakow nie wygeneruje.
napisalem 'chyba tylko do zapetlenia', bo chociaz praktycznie odrzucam calkowicie te opcje, to moja niewiedza nie pozwala mi jej obalic - okreslony ciag znakow wygeneruje hash identyczny temu ciagowi znakow. to by byl po prostu lol ;p

nalezy pamietac tez o tym, ze crackerzy znaja sie na tym lepiej niz my, a co dopiero szaraczki tworzace hasla. i nawet jesli wymagamy ^[a-zA-Z0-9!"£$%^&*()]{10-20}$ do hasla to wg 'poradnikow' do hasel ktos wymysli jestem basia i zamieni Je$+emKa$14 czy cos podobnego, to hackerek znajac wymagania nie bedzie sie poslugiwal bf, ale zlamie te osobe i wygeneruje slownik, bo bedzie wiedzial, ze ludzie zazwyczaj zamieniaja znaki na inne konkretne.
nie zrozumcie mnie zle - uwazam, ze ow haslo jest o niebo lepsze od kasia ;ppp

wspomnialem wczesniej o mozliwosci dwustronnego szyfrowania. nie chodzi moze tutaj tyle o hasla co o rozne dane, ktore powinny byc kodowane. wtedy znow sol sie pojawia i chyba jest niezastapiona ;p

co do porzedniego postu:
z tego co [nie] wiem to sha0 i 1 podobnie jak md4 i 5 generuja wyniki zawierajace znaki ze zbioru {0-9a-f} czyli 16^4 to 64k kombinacji, co wydaje sie banalna liczba do podstawienia, zeby uzyskac slowo kolizji i uzyskac dostep. w takim wypadku sol tez nie pomoze, bo jesli ktos zna algorytm, to zna i sol, czyli tez moze dojsc do poczatkowego hasla

i na koniec, tak na rozweselenie
co powiedzie na haslo typu '¬' w sensie jeden jakis dziwny znak, ktory nie nalezy do zbioru znakow alfanumerycznych. oczywiscie jak ktos idzie porzadnie na bf, to zacznie od poczatku, ale co jesli ktos chce zaoszczedzic troche czasu i zacznie od hasel 3-znakowych? ;p

MD5 ma 16^32 możliwych kombinacji.
Hasła typu: 't¬sdમﬗ' IMO rozwiązują problem ataku typu BF, ale powodzenia życzę w nakłonieniu ludzi do stosowania takiego hasła

Osobiście polecam stosowanie crypt().
Wszystkie metody hashowania które podaliście powyżej, są metodami jednostronnymi, więc w czystej teorii NIE MA możliwości odkodowania nawet pojedynczo zahashowanego hasła. Jednak Rainbow Tables (tablice tęczowe) pokazuje że odkodowanie (w sposób dość nietypowy, ale zawsze ) takiego hasha jest jak najbardziej możliwe. Przed tą metodą teoretycznie możemy się zabezpieczyć hashując dwukrotnie, ale MUSICIE pamiętać, że hashując na md5 chociażby 28-znakowy wynik sha1, zwiększamy ilość kombinacji które w wyniku dadzą nam ten sam ciąg md5 :-). Wiem że trafienie na drugi taki sam ciąg jawny, który da tam w wyniku ten sam hash md5 jest jak szóstka w totolotku 3x pod rząd, ale skoro mówimy tu o bezpieczeństwie metod hashujących, to są lepsze metody.

Tablice tęczowe są z kolei zbiorem hashy wygenerowanym za pomocą swoistego brute-force.
Wyglądają one mniej więcej tak:
a 0cc175b9c0f1b6a831c399e269772661
b 92eb5ffee6ae2fec3ad71c777531578f
c 4a8a08f09d37b73795649038408b5f33
(...)
aa 4124bc0a9335c27f086f24ba207a4912
ab 187ef4436122d1cc2f40dc2b92f0eba0
ac e2075474294983e013ee4dd2201c7a73
(...)

I wierzcie mi, że trafiłem na kilka online'owych skryptów które potrafiły odhashowały mi np. hasło brzmiące "dw00jka" - kto z nas nie używa czasem tego typu haseł?
A co jest takiego cudownego z funkcją crypt() ? I dlaczego jest taka bezpieczna? Zaraz podam Wam przykład.
Oto przykładowe hashe crypta:

a - $1$sxKPdmqP$BHtXNcPix.QTIDAWgozat0
a - $1$d7h5X5sH$VzC4/sM4.FM1624O0Kd7I1
a - $1$ED8ONypj$gSpKFzkcSae1hXVnrf7Cq.

Jak widać powyżej, crypt() jest algorytmem wykorzystującym losowość. Wyobraźcie sobie, jak rainbow tables miałoby sobie z tym fantem poradzić . Pytanie pewnie pojawi się, jak przy tym cholerstwie napisać funkcję porównującą hasło z hashem, skoro hash jest losowy ?
Sprawa jest prosta:



Jak widać z powyższego, przy porównaniu szyfrujemy cryptem za pomocą stworzonego wcześniej hasha. W taki sposób trzeba by było tworzyć tablicę tęczową nie za pomocą ciągów jawnych, tylko za pomocą hashy, których jest N na każdy możliwy ciąg jawny, co oczywiście graniczy z niemożliwością. Właściwie nasuwa się wniosek, że jedyna możliwa metoda złamania tego to zwykły brute-force. A nawet najlepsza znana metoda szyfrowania NIE zabezpieczy nas przed brute-forcem.

Wcześniej używałem md5(sha1('haslo')), ale teraz doszedłem do wniosku że crypt jest wystarczająco bezpieczny i nie trzeba wydziwiać.

Pozdrawiam

sha1 AFAIK nie jest wiele bezpieczniejsze od md5. Ja stosuję sha256/sha512. No i też wypadałoby zmianiać sól co jakiś czas - ja zmieniam sól użytkownika przy każdym logowaniu.

Nie wiem czy zmiana soli po zalogowaniu ma duży sens, spowalnia to (lekko, ale zawsze) - działanie programu. Sądzę że losowe ziarna dla poszczególnych użytkowników, nawet z określonej puli, mają większy sens. Choć o czym my rozmawiamy, jeśli ktoś robi WP, może jest sens na to zrwacać uwagę, ale w przypadku mniejszych portali sądzę że kodowanie do (sha1 + ziarno) i ponowne zakodowanie starczy zupełnie...

Mikz -> crypt() to nie żaden algorytm, tylko uniwersalna funkcja dostępowa do kilku znanych algorytmów występujących zależnie od systemu, implementacji itd. - wśród nich jest m.in. MD5. Tak samo jedyna losowość, jaka tam występuje, to generowanie soli i nie ma to nic wspólnego z losowością samego algorytmu. Inaczej by się z tego w ogóle korzystać nie dało .

crypt() działa na takiej zasadzie, że jeśli wywołane jest z jednym argumentem, generuje losową sól zwraca hasz z doklejoną solą. Możemy także sól określić jawnie i to jest wykorzystywane przy sprawdzaniu hasła. Podajemy wtedy zahaszowany ciąg, ponieważ do niego doklejona jest sól i funkcja może sobie z niego ją odczytać. Nie ma w tym żadnej magii, to samo można uzyskać, jawnie określając algorytm haszujący:



Jedyna różnica jest taka, że tutaj musimy sól sami zapamiętywać. Jako obrona przed tęczowymi tablicami jest to dobra metoda, ponieważ w niej należałoby tworzyć osobne tęczowe tablice dla każdej możliwej soli. Nie ma tu żadnej magii, tylko jest to ładny interfejs do tej samej techniki, która chyba została już tutaj wcześniej opisana nawet. Same tęczowe tablice też mają trochę bardziej skomplikowaną strukturę, niż to napisałeś

Zyx -> z tą solą to chyba dość oczywiste, ale dopóki jest ona generowana losowo, dopóty można powiedzieć że jest wykorzystywana losowość przy generowaniu hasha.
Jeśli chodzi o tablice tęczowe, wiem mniej więcej na czym one polegają i chyba swoim opisem nie odbiegłem daleko od ich istoty .

Jednak kiedy odrzucimy możliwość skorzystania z rainbow tables przy jednostronnym hashu (właśnie za pomocą tej "losowości" crypta), wtedy można swobodnie stwierdzić że nie ma realnej szansy na złamanie takiego hasha, więc jest on bezpieczny.
Podwójne hashowanie staje się w tym momencie po prostu zbędne .

Ja w przyplywie entuzjazmu bawie sie innaczej baza danych oczywiscie z tym ze haslo zapisze sobie w kolumnie dajmy na to lastlogin a w kolumnie pass przechowam sobie jakis random z literek i cyferek i wiem ze predzej czy pozniej ktos sie odpowiednio zreflektuje daj im odpowiednio duzo czasu a wszedzie sie dostana. Kwestia druga jest taka ze im wiecej zabezpieczen tym mniejsza wydajnosc i nie wydaje mi sie ze sztuka jest zrobic aplikacje do ktorej sie nikt nie wlamie sztuka jest dobrze to wywazyc, aby jednak wiedziec jak to wywazyc mysle ze trzeba monitorowac ruch... i postawic kilka sprytnych alertow. Osobisie ostatnio bawie sie sesjami zamieniam ich id po kazdym wywolaniu, kontrola ip, kontorla przegladarki i rozne takie bajery ktore napewno obnizaja wydajnosc aplikacji i nie zawsze sa konieczne. Mysle rowniez ze optymalizacja js tez jakos podnosi bezpieczenstwo kod w jednym ciagu i nazwy funkcji/zmiennych typu a1,a2 etc.. moga szybko zniechecic md5 to nie wszystko a jak ktos bedze bardzo chcial to i z tym sobie poradzi... do kwestji zabezpieczen podchodze jak do zabawy a jesli komus uda sie odczytac 32 z bazy danych w kolumnie pass po zlamaniu hasha moze sie okazac ze nic z tego nie wyniknie tylko dlatego bo hash byl przechowywany w bazie na wspak... troche wyobrazni paniowie...

Ja za to zabezpieczam się odrobiną sztucznej inteligencji i firewallem - wystarcza w zupełności. Oczywiście baza danych stoi na innym serwerze, php stoi na VPS'ach a uprawnienia do bazy danych są tak dobrane, że użytkownik nie ma możliwości odczytu hasła (są odpowiednie funkcje służące sprawdzaniu poprawności oraz zmianie.

To jak do tej pory wystarczyło a nie żadne hashowanie wielokrotne.

3 grosze..

jak ktos zna aplikacje TrueCrypt to odsylam do specjalistow, do ich dokumentacji o wielokrotnym hashowniu, najbardziej zalecana metoda to wlasnie wielokrotne hashowanie przy uzyciu bodajze 3 algorytmow

mozna tez zobaczyc krotkie opisy kazdej metody wielokrotnego hashowania w okienku wyboru metody hashowania partycji lub wyboru klucza, nie pamietam dokladnie, tam sa krotkie opisy dlczago i ktora jest rekomendowana

I pisze to osoba, która kilka zdań wcześniej powiedziała, że zabezpieczenie aplikacji traktuje jak zabawę. Że coś co właściwie nie wpływa na wydajność aplikacji to "bajery" typu regenrowanie ID sesji i można się ich pozbyć celem "podniesienia wydajności", a na pierwszy front obrony idą nie-userfriendly nazwy zmiennych/metod w JSie (który defacto do jakichkolwiek zabezpieczeń/obrony nie może być używany).

Poczytałem ten topic, jak i artykuł o hashowaniu do którego link ktoś tu zamieścił.

Więc tak, celem całego tego hashowania jest uniemożliwienie lub chociaż maksymalne utrudnienie dojścia do hasła posiadając hash - a w posiadanie hasha ktoś może wpaść tylko włamując się do bazy danych.

Pogrzebałem troche w dokumentacji funkcji hashowania na php.net. Znalazłem tam ciekawą funkcję: hash_hmac. Generuje on hasha za pomocą podanej przez nas metody oraz podanego przez nas klucza, na podstawie którego jest generowany hash używając metody HMAC. Ustalając np. 512 znakowy klucza, potencjalny haker posiadający hasha raczej nie ma szans na dojście do hasła, na jaki wskazuje dany hash - no chyba że posiadałby tablice tęczowe do każdego z 512 znakowej kombinacji klucza, czyli ponad 200 tysięcy tablic tęczowych Nawet posiadając ten klucz, musiałby najpierw stworzyć tablice tęczową dla HMACa z danym kluczem. Możnaby ewentualnie dla każdego hashowanego hasła ustalać inny klucz, np. losowy, wtedy haker musiałby dla każdego hasła tworzyć osobną tablicę tęczową :-)

Co sądzicie o tej metodzie?

Wspaniały pomysł. Tylko taki losowy klucz też chyba gdzieś musisz mieć zapisany? A gdzie go zapiszesz jak nie w bazie danych?

Załóżmy jednak, że masz jeden wygenerowany klucz i trzymasz go w jakimś pliku konfiguracyjnym. Jaki problem mając dostęp do bazy danych uzyskać dostęp do plików i odczytać ten klucz?

Jak już ktoś napisał - cała potęga hashowania nie opiera się na tajności sposobu, tylko na nieodwracalności (na mocnym algorytmie). Możesz dać chociażby 1024-znakowe hasło + 1024-znakową sól, ale jaką masz pewność, że 2-znakowe będzie miało inny skrót? (pomijam odporność obu haseł na łamanie BF)

Hm, ale ten mój pomysł miałby uniemożliwić dojście do hasła za pomocą dostępnych w necie baz danych z rozshashowanymi hashami. Wtedy musieliby sobie sami zrobić tablicę od nowa dla danego klucza :-) A że pozna klucz - możnaby własnie w bazie zapisywać te losowe klucze, wtedy nawet jakby je znał, musiałby dla każdego hasła utworzyć osobną tablicę tęczową, a takie coś to już byłby wyczyn Orientuje się ktoś ile czasu wymaga utworzenie takiej tablicy tęczowej lub takie bazy danych, jakie są dostępne w necie (wpisujemy hash i dostajemy hasło, z którego został wygenerowany)?

Poczytaj o kolizjach.
Ja mam taki projekt na Programowanie Równoległe i Rozproszone. Ściślej odpowiem jak go zrobię Potrzeba na to i bardzo dużo czasu i bardzo dużo miejsca na dysku. Ogólnie rzecz biorąc im więcej tym lepiej, bo raczej trudne byłoby wygenerować każdą możliwą kombinację.

Nie rozumiem, co do generowania hasha za pomocą hash_hmac mają kolizje? W chyba każdej metodzie hashowania istnieje jakieśtam prawdopodobieństwo powstania kolizji, ale hashowanie na podstawie losowego klucza, który jest później zapisywany, raczej zmniejsza to prawdopodobieństwo :-)

Mylisz się. Prawdopodobieństwo powstania kolizji zależy od długości hasha, czyli od ilości możliwych kombinacji.
Jeśli takich kombinacji będzie N, to po wygenerowaniu 2 hashy masz 1/N prawdopodobieństwo, że nastąpiła kolizja. Im większe N, tym więcej trzeba się natrudzić, żeby trafić na ten sam wynik.
Skoro długość hasha jest określona, znaki w nim to 0-f, to ilość kombinacji jest skończona. Ilość ciągów wejściowych jest nieskończona, bo mozesz budować coraz dłuższe. Z tego jednoznacznie wynika, że kolizje są [wystarczyłoby (ilość_kombinacji_hasha + 1) ciągów wejściowych, żeby na 100% zdarzyła się jakaś kolizja]. Nieważne jak bardzo losowy ciąg będziesz kodował. Pytanie tylko jak trudno je znaleźć

Hm, czyli jeżeli zmienię metodę hashowania z sha1 na powiedzmy sha512 (128 znaków), ten mój pomysł z hash_hmac powinien być ok? :-)

No i ja już mówie o tworzeniu hasha na podstawie jednego tylko klucza dla wszystkich kont, wtedy przecież prawdopodobieństwo kolizji jest takie samo jak przy surowym hashowaniu.

Jeśli pracujesz dla Amerykańskiej armii i ochraniasz hasłem 'red button', to tak Hash sha1 ma długość 40 znaków. Każdy z nich może być hexadecymalną wartością. Czyli ilość kombinacji sha1 to 16^40 = 1.46150164 * 10^48 (wg. Google). Przy sha512 ilość ta wzrasta do 16^128 = 1.34078079 * 10^154. Nie muszę Ci chyba mówić jak duże są to liczby

Dodawanie soli (klucza) ma za zadanie wykluczyć możliwość słownikowego ataku. Jeśli ktoś ma hasło password, to odnalezienie go nie jest trudne (porównywanie znalezionego hasha z generowanymi kolejno skrótami dla słów ze słownika). Ale jeśli dodasz sól, to hasło będzie wyglądało np. tak: password$%^HNJGCFksdfsdbj^*12. Wtedy słownikowy atak na nic się nie przyda (zakładając oczywiście, że hackerujący nie zna naszej soli).

Jeśli bardzo bredzę to proszę kogoś o poprawienie mnie. Ekspertem od kryptografii nie jestem

Dzięki za wytłumaczenie celu dodawania soli, nie mogłem tego do końca zrozumieć :-)

Ten mój pomysł działałby podobnie, ale według mnie lepiej od soli - wtedy atakujący musiałby znać klucz który wrzucam do hash_hmac, żeby cokolwiek zdziałać - nie posiadając go musiałby chociażby dla ataku słownikowego, przeprowadzić go dla wszystkich kombinacji klucza z hash_hmac Wystarczy utworzyć taki klucz z powiedzmy 512 znaków, i dojście do hasła wejściowego jest praktycznie niemożliwe :-)

Czekam na Wasze komentarze co do stosowania hash_hmac do zatajania hashów haseł :-)