podwójne hashowanie haseł, ogólnie n-hashowanie Opcje

[nospor]

w związku z lekkim OT w pewnym temacie, który rozwinął się w ciekawą dyskusję, temat rozdzielam. Dotyczy on:
Czy podwójne (n-te) hashowanie hasła jest bezpieczniejsze, od pojedynczego hashowania

md5 sie nie odkoduje. mozna trafic na rozwiązanie metodą brute force. Dla tej metody jednak jest bez roznicy, czy ty dane haslo przepuścic przez md5 raz, dwa czy milion razy (IMG:style_emoticons/default/wink.gif)

Posty będące duplikacją postów już zawartych w temacie, będą bez ostrzeżenia usuwane. Ma to zapobiedz tworzeniu się zbędnego śmietnika

[wijet]

Ja też myślalem że przepuścić przez md5 dwa razy będzie lepiej, ale ja to bym zrobil tak.

[PHP] pobierz, plaintext 
<?php
 
$tajny_ciag = '23mjdkifjS1lpo321lpSAo5c90sawe3';
 
$zaszyfrowane = md5($tajny_ciag.md5($tajny_ciag.$_POST['pass']));
 
?>
[PHP] pobierz, plaintext 

[mike]

Haszowanie dwa razy jest bez sensu, no bo nawet jeśli działa to co z tego?
W takim razie dlaczego nie 10 razy.

To jest jak z kostką Rubika. Jak już pomieszałeś dobrze, to każde kolejne przekręcenie ścianki nic nie daje.
Nie da się bardziej pomieszać.

A md5 jest algorytmem mieszającym.

P.S.
Wiecie dlaczego polskim matematykom udało się rozszyfrować Enigmę?
Bo niemieccy projektanci założyli, że jak kodowanie będzie odbywać się dwa razy to wzrośnie efektywność.
A stało się to przyczyną jej złamania (IMG:style_emoticons/default/wink.gif)

[FiDO]

rety, co wy żeście się przyczepili tego podwojnego hashowania. jeszcze ten tajny ciąg...
Metodzie brute force jest to wszystko jedno. Proponuje poczytać coś na ten temat. md5 do nie jest szyfrowanie dwustronne, że trzeba kombinować. Na to jest tylko jedna metoda by odgadnąć haslo: brute force, czyli tworzenei kombinacja hasla do bólu, aż się natrafi na takie co pasuje. Możecie te haslo mlynkiem mielic, ale jak pasuje to pasuje i juz (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

No niezupelnie. Zgadzam sie z tym, ze w gre wchodzi tylko b-f (aczkolwiek na md5 juz sa jakies bardziej inteligentne sposoby), tylko ze jest roznica dla b-f czy atakujesz haslo, ktore ma 7 znakow czy tez takie, ktore ma 32 znaki.
Zakladajac, ze haslo brzmi 'tajne123' to probujac je zaatakowac przy pojedynczym hashowaniu b-f powinien sobie poradzic w czasie takim, ze oplaca sie czekac (tak na oko przy tej dlugosci sadze, ze jest to do rozlozenia w czasie gora kilku dni przy pesymistycznym zalozeniu na domowym sprzecie), w koncu to 'tylko' 8 znakow. Jesli hashujemy podwojnie to pierwszy cykl b-f bedzie musial zwalczyc ciag 32 znakowy (litery i cyfry), a tego juz tak szybko zrobic sie nie da. A nawet jak juz sie po wielu miesiacach/latach uda to otrzymamy w wyniku jeszcze jeden hash i zabawa od nowa.
To tak na pierwszy rzut oka.. jednak pamietam przez mgle z inzynierii bezpieczenstwa, ze koles cos mowil o nieskutecznosci podwojnego szyfrowania, nie pamietam jednak czy tyczylo sie to tez hashowania. Jesli ktos widzi jakas dziure w rozumowaniu, ktore przedstawilem wyzej to smialo.. chetnie sobie odswieze wiedze, a przez ksiazki kopac mi sie teraz nie chce (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[rbart]

Osobiście niewiem po co to podwójne kodowanie md5 skoro i tak qbase zastanawia się nad zapamiętywaniem użytkownika przez cookies. Poreszto czy to nowe zabezpieczenia fort'u knox (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) jeżeli nie to całe kodowanie służy tylko do tego że jeżeli już komuś uda się odczytać dane z bazy to żeby niemógł wyciągnąć haseł (znaczy się bez problemu). Md5 zapewnia bezpieczenstwo o wiele wyższe od tego które będzie potrzebne.

Teoretycznie :

Jakie kolwiek złamanie hasła wiąże się jedynie z metodą b-f o odkodowaniu md5 mogą wszyscy zapomnieć. I w tym przypadku podwójne zakodowanie md5 może spełnić swoją rolę ponieważ wtedy b-f będzie musiał wygenerować 128 bitowe ciągi znaków. o ile dobrze pamiętam to jest 32 znaki co napewno będzie trudniej rozszyfrować b-f'em z drugiej strony jeżeli ktoś już wyciągnął zakodowane hasła z bazy to napewno sprawdzi czym i jak były kodowane i wtedy okazuje się że podwujne kodowanie jest bez sensu ponieważ wspomniana osoba dalej posłuży się b-f tylko będzie musiała go dwa razy kodować i dopiero sprawdzić z rekordem w bazie.

Ten post edytował rbart 22.03.2006, 20:29:03

[sobstel]

md5 sie nie odkoduje. mozna trafic na rozwiązanie metodą brute force. Dla tej metody jednak jest bez roznicy, czy ty dane haslo przepuścic przez md5 raz, dwa czy milion razy (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) Moze się okazać, ze podwojne shashowanie hasla, zostanie rozwiązane szybciej, niż byś to zrobil tylko raz (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) tak więc nie kombinuj (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

widze wlasciwie tylko jeden przypadek kiedy kombinowanie z md5 ma sens. istnieją w necie duze bazy z wygenerwoanymi hashami slow ze slownika, ich kombinacji, itp. (podajesz 32-znakowego hasha a on ci wyrzuca co sie pod tym kryje). jesli ktos w jakis sposob wszedl w posiadanie np. hasel zakodowanych md5 wtedy uzywajac powyzszej bazy stosunkowo łatwo wyciągnie większość haseł.
ale powiedzmy sobie jasno ze jesli ktos rzeczywiscie wejdzei w posiadanie hasel i loginow to znaczy ze aplikacja jest dziurawa jak sito, ale to juz inna sprawa (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

oczywiscie przy metodach typu brute-force to nie gra zadnej roznicy chocby ktos zrobil crypt, md5, sha1, przemieszial wszystko i jeszcze powtorzyl kilka razy ;-)

co do odkodowania md5, jak juz ktos kiedys ladnie zauwazyl, gdyby to bylo mozliwe to mielibysmi najlepszy w historii algorytm kompresji... wszystko mozna do 32 znakow (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[Aztech]

[offtopic mode on]

co do odkodowania md5, jak juz ktos kiedys ladnie zauwazyl, gdyby to bylo mozliwe to mielibysmi najlepszy w historii algorytm kompresji... wszystko mozna do 32 znakow

(IMG:http://forum.php.pl/style_emoticons/default/laugh.gif) (IMG:http://forum.php.pl/style_emoticons/default/laugh.gif)
Rozbroiłeś mnei tym wnioskiem, w życiu bym nie pomyślał w tych katergoriach o md5
[offtopic mode off]
Co do podwórjnego md5 to nie widzę sensu, wszystkie argumenty zostały już powiedziaane wcześniej.

[nospor]

Zakladajac, ze haslo brzmi 'tajne123' to probujac je zaatakowac przy pojedynczym hashowaniu b-f powinien sobie poradzic w czasie takim, ze oplaca sie czekac (tak na oko przy tej dlugosci sadze, ze jest to do rozlozenia w czasie gora kilku dni przy pesymistycznym zalozeniu na domowym sprzecie), w koncu to 'tylko' 8 znakow. Jesli hashujemy podwojnie to pierwszy cykl b-f bedzie musial zwalczyc ciag 32 znakowy (litery i cyfry), a tego juz tak szybko zrobic sie nie da. A nawet jak juz sie po wielu miesiacach/latach uda to otrzymamy w wyniku jeszcze jeden hash i zabawa od nowa.

Przyznam szczerze, iż nie wiem jak robi się w praktyce ataki b-f. Nigdy nie robilem (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) Wiem z teorii tylko jak dzialają.
Ale przypuśćmy, ze taki atak polega na ciąglym wysylaniu requesta do strony, gdzie należy się zalogować. W request wysylane jest haslo. Jak wiemy jest to haslo wówczas w postaci jawnej (nie hashowane). Tak więc nie ma znaczenia, ze hash będzie mial 32 bajty czy też więcej. Nie ma znaczenia, ze po stronie serwera bedzi dodawany jakiś tajny ciąg do tego. Znaczenie ma to, ze haslo ma 8 znaków i wygenerowanie ich wszystkich kombinacji nie ma już zadnego związku z metodami hashowania na serwerze.

[lenczewski]

hmmm. a jednak będę odmiennego zdania, niż cześc tu obecnych.
Zakładając, że ktoś wyciagnie hasło uzytkownika (ciastka, itp.) i będzie ono zakodowane md5($hasło), rozszyfrowanie tego nie zajmie dużo czasu (no chyba, ze ma więcej niż 7 znaków), natomiast rozszyfrowanie md5(md5($hasło)) potrwa raczej zbyt długo ...i yu w zupełności zgadzam się z FIDO.
Lektura: Rainbow Tables

co do odkodowania md5, jak juz ktos kiedys ladnie zauwazyl, gdyby to bylo mozliwe to mielibysmi najlepszy w historii algorytm kompresji... wszystko mozna do 32 znakow

(IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) istnieje jeszcze coś takiego na kolizje kodowania, tzn. 32 znaki muszą się kiedyś powtarzać, dlatego jeżeli będziesz chciał coś "odkompresować" (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) możesz otrzymać zupełnie coś innego, a taka szansa jest wprost proporcjonalna do długości ciągu początkowego.

Wniosek nasuwa się mi prosty, chyba stosowanie podwójnego md5() nie obciąza tak bardzo serwera, żeby tego nie używać. na pewno nikt na tym nie straci, a do zzyskania jest o wiele więcej. Zawsze lepiej jest komuś (potencjalnemu "chackerowi") coś utrudnić, niż ułatwić.

tak swoją drogą, baza danych hashów md5() samych liczb (do 7 znaków) zajmuje ok. 1.3 GB (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) złamanie takiego hasła (przeszukanie bazy) to ok. 3 min.

-edyta:
jeszcze raz [OT]:

co do odkodowania md5, jak juz ktos kiedys ladnie zauwazyl, gdyby to bylo mozliwe to mielibysmi najlepszy w historii algorytm kompresji... wszystko mozna do 32 znakow

jest algorytm (stosunkowo prosty) gdzie z pliku powiedzmy 200kb po rozpakowaniu otrzymamy jakieś 60GB, wszystko zalezy od tego co pakujemy.

Ten post edytował lenzcewski 23.03.2006, 20:21:59

[My4tic]

A co powiecie o słownikach hashy w md5 których pełno w necie? W takim wypadku podwójne hashowanie czy kombinacje z 'tajnym ciagiem' zaczynają mieć sens. Zgadzam się ze md5(md5(pass)) samo w sobie nie ma większego sensu ale żeby uniknąć metody słownikowej może być przydatne.

[nospor]

Kurka wodna, jak to potrafią czlowiekowi wodę z mózgu zrobić.... (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
Jak tak czytam kolejne wypowiedzi, to zaczynam wierzyć w lekki sens tego kombinowania (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

edit: oczywiscie mam na mysli sytuację, gdy ktoś wykradnie nam hasha. Bo gdy b-f leci bezposrednio na stronę, to takie kombinowanie jest bez sensu

[My4tic]

Zgadza sie - na b-f nic sie nie poradzi ale podwojny hash dla takiego czegoś:

http://gdataonline.com/seekhash.php

to już bedzie problem.

[lenczewski]

nospor: dla bezpośredniego ataku na strone (remote) mało co ma sens. Zakładając, że serwer odpowiada czy jest dobre hasło czy nie w czasie powiedzmy 0,5 s. (co jest czasem chyba bardzo dobrym (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) , daje to 172 800 zapytań na dobę, przy haśle powiedzmy pięcio literowym (małe litery bez cyfr i innych znaków) przy najbardziej pesymistycznym podejściu

Kod

24^1+24^2+24^3+24^4+24^5

daje to 8 308 824 hashów
Czyli jakieś 48 dni, nie licząc padów serwera (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Exploitów do wyciągnięcia haseł z phpBB jest masa. ...a z tamtąd już tylko prosta droga do gdata.

-add:
oczywiście dodanie do hasła znaków innych niż alfanumeryczne spowoduje koszmarne utrudnienie w złamaniu takiego hasła, ale to już raczej mentalność użytkowników, a nie administratora ;(

Ten post edytował lenzcewski 23.03.2006, 22:55:25

[SHiP]

Co do kodowania 2 x md5 heh a nie łatwiej użyć kodowania sha1()? Dużo mniej znany sposób więc i baze danych hashów nie bedzie łątwo znaleźć przez co napewno będzie ciężej go złamac ;] Dla utrudnienia można kodować w sh1 i ucienać 8 znaków przez co bedzie to wyglądało jak md5 ;] Nikt nie zauważy =)

Co do COOKIE + md5 ;] skoro mamy hasło w md5 to po co je odkodowywać? Wystrczy spreparować odpowiednie ciastko i mamy dostęp do kona ;]

Ten post edytował SHiP 23.03.2006, 23:03:19

[lenczewski]

hmmm. po co?
jeżli masz odkodowane hasło, szansa, że użytkownik ma takie samo w mailu #1 mailu #2, innych kontach, homebanking, itp., a wszystko dzięki Twojej stronie i "systemu zabezpieczeń" na niej.

co do Twojego sposobu z SHA1() wydaje się być bardo dobry.

ja użwam od jakiegoś czasu megody w której koduje $hasło . $mail funkcjami md5(md5()) (i taki zapis jest w kodzie źróodłowym) następnie w innej cześci trafia to do bazy, gdzie jest standartowe pole typu passwd.
Jak ktos dostanie moje baze bedzie mam nadzieje, ze bedzie lekko wprowadzony w blad, a przy okazji powstała optymalizacja bazy (w jednej kolumnie trzymam dwie rzeczy i zamiast adresu e-mail + 32 znaki na hasło, mam 16).

Dlatego namawiam wszystkich do nie stosowania standartowych rozwiazan typu md5() i po sprawie. Dołączenie choćby jednego znaku (~!@#$%^&*(){}:"<>?/.,;'[]) znacznie utrudni sprawę. Jednak i tak nie daje to 100% metody na nie odkodowanie. Jeżeli ktoś dostanie kod źródłowy strony, sam może napisać taką funkcję substr(sha1($tajne), 0, 32), a wtedy b-f i kwestia czasu (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Nie popadajmy jednak w panikę, metod na nieautoryzowany dostęp do aplikacji jest napradwdę mnóstwo. Poprostu róbcie rzeczy nieszablonwe (tyczy sie kodowania hasel), co do reszty, coz jest SQL Injection, Code injection, Cross-Site scripting, HTTP Response Splitting, Directory traversal, Session fixation, Session injection... i pewnie jeszcze milion innych metod.

Coż jest miecz, jest tarcza, ale i miny przeciw piechotne, granaty, rakiety bliskiego, średniego i dalekiego zasięgu ...i pewnie miltion innych (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Ten post edytował lenzcewski 24.03.2006, 06:54:50

[chomiczek]

Dla utrudnienia można kodować w sh1 i ucienać 8 znaków przez co bedzie to wyglądało jak md5 ;] Nikt nie zauważy =)

Z tym ucinaniem to chyba nie jest za dobry sposób z uwagi na to, że chyba jest spore prawdopodobieństwo żeby początkowy fragment sie zdublował z jakimś innym.

Co do MD5 to jest podobno wydajny sposób na podstawienie swojej zawartości zawierające taka samą sume kontrolną (md5). Sposób ten opracowali jacyś naukowcy i de facto nie został jeszcze opublikowany, ale..

P.S. jak znajde ten artykuł to dokleje linka.

-add:
Co do stosowanie np. samego MD5 to ja osobiście np. uploadując fotki na serwer wprowadzam nazewnictwo typu: md5('#d.icA'.mysql_inserted_id()); dla dużych fotek i dla miniaturek md5('#m.icA'.mysql_inserted_id()); sądze, że jest to dobry sposób a jesli ktoś nie ma dostępu do kodu to nie wie nawet jak to ugryźć.

Ten post edytował chomiczek 24.03.2006, 09:07:53

[lenczewski]

http://www.hakin9.org/pl/attachments/md5_pl.pdf
http://www.stachliu.com/collisions.html
http://www.google.com/search?client=opera&...=utf-8&oe=utf-8

[kszychu]

hmmm. po co?
jeżli masz odkodowane hasło, szansa, że użytkownik ma takie samo w mailu #1 mailu #2, innych kontach, homebanking, itp., a wszystko dzięki Twojej stronie i "systemu zabezpieczeń" na niej.

Debile, którzy używają jednego hasła do wszystkiego sami są sobie winni! Jak można używać takiego samego hasła do logowania na forum i logowania do banku?!
Najlepszym zabezpieczeniem i tak pozostanie ludzka inteligencja. Wtedy nawet jeżeli ktoś odkryje Twoje hasło do strony, to będzie znał tylko... hasło do strony. I nic więcej.

[E-d]

md5 da się odhaszować.
http://md5.rednoize.com/
Więc lepiej używać sha1

[lenczewski]

krzychu:
nie zmienia to faktu, że ktoś uzyskał dostęp do jego haseł poprzez nasz serwis, stronę, czy co tam innego. Przy Twoim rozumowaniu po co wogule kodować hasła?

[nospor]

md5 da się odhaszować.
http://md5.rednoize.com/
Więc lepiej używać sha1

To jest akurat przykład na łamanie "łatwych haseł". Link ten, lamie hasla, które skaladają sie tylko z liter. Przykladowo zlamal mi takei hasla:
kaczor
mama
ale wystarczylo, ze zamiasta a dalem 4, albo zamiast o dalem 0 (zero), i juz nie znalazl:
k4czor
kacz0r
m4ma

W łamaniu hasel duża wina leży po stronie uzytkownika. Od stopnia skomplikowania swego hasla. Im mniejszy stopien, tym szybciej go zlamac.

Kiedys jeden z największych hackerów na świecie powiedzial, że byl najlepszy nie dlatego ze umial lamac kody, ale dlatego, ze znal mentalność ludzką, która jest największym sprzymierzeńcem hackera. To zadzwonil do Pani krysi, powiedzial ze zapomnial hasla lub jakas inna bajeczka i ona mu podawala wszystko jak na tacy.
Albo zbieral dane o osobie. Imie żony, dziecka i takie tam. Mamy niestety (jako ludzie) takie sklonnosci, ze wlasnie takie nadajemy hasla: imie zony, rok urodzenia lub podobne. Nie mowię ze wszyscy (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) Ale spora grupa osób tak robi.

Podobnie jest tutaj. Chcemy miec bezpieczne hasla? Zadbajmy oto sami (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Oczywiście jesli i dany serwis nam w tym pomoże, to też nie zaszkodzi (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

ps: mojego hasla nie zlamal (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

[kszychu]

Przy Twoim rozumowaniu po co wogule kodować hasła?

Nie zrozum mnie źle, nie twierdzę, że nie należy kodować haseł. Tak czy inaczej jednak, każde zabezpieczenia można złamać.
Mówimy tutaj jednak o sytuacji, w której cyfrowym zamkiem najnowszej generacji zamykamy drewniany składzik z węglem. Da się obejść nawet taki zamek, tylko uważam, że nawet zwykła kłódka byłaby wystarczającym zabezpieczeniem, bo po co się włamywać do komórki z węglem.
Przestrzegam natomiast przed sytuacją, w której jeden klucz służy nam do wszystkich zamków w domu, bo ktoś wścibski, "rozpracowawszy" zamek do komórki z węglem, spróbuje tym samym kluczem otworzyć sejf za obrazem.

A tak na marginesie: jeżeli ktoś włamie Ci się do systemu i wyciągnie hasche haseł, to wyciągnie równieżdowolne inne informacje, więc po co miałby się bawić w odkodowywanie tych haseł?

http://md5.rednoize.com/

Nie zdziwiłbym się, gdyby ten serwis "karmił" swoją bazę wpisywanymi tam hasłami...

[FiDO]

Przestrzegam natomiast przed sytuacją, w której jeden klucz służy nam do wszystkich zamków w domu, bo ktoś wścibski, "rozpracowawszy" zamek do komórki z węglem, spróbuje tym samym kluczem otworzyć sejf za obrazem.

A tak na marginesie: jeżeli ktoś włamie Ci się do systemu i wyciągnie hasche haseł, to wyciągnie równieżdowolne inne informacje, więc po co miałby się bawić w odkodowywanie tych haseł?

Na przyklad po to o czym napisales w pogrubionym akapicie. Majac haslo danej osoby mozna sprobowac tym samym haslem wejsc na jakies inne serwisy, w ktorych jest ona zarejestrowana.. kto wie czy ludzie nie daja takich samych hasel do maila, na ktorego sie zarejestrowali, a majac baze prawdopodobnie jestesmy w ich posiadaniu, a to juz cos.
Ewentualnie ktos moze miec po prostu ochote namieszac ludziom na kontach, takich dowcipnisiow tez nie brakuje. Nie zawsze motywem musza byc jakies profity.

http://md5.rednoize.com/

Nie zdziwiłbym się, gdyby ten serwis "karmił" swoją bazę wpisywanymi tam hasłami...

Przeciez on tak wlasnie robi. Jak wpiszecie haslo nie bedace hashem md5, ktorego jeszcze nie ma w bazie to pojawia sie informacja "Result saved", wiec to jest baza budowana przez ludzi.

Co do podwojnego hashowania to ja sugeruje jeszcze troche inna metode. Samo md5(md5) ma taka wade, ze kilka osob z tym samym haslem (zdziwilibyscie sie jak duzo osob uzywa powiedzmy 'standardowych' 123456 czy czegos podobnego kalibru) otrzyma takiego samego hasha. Nie jest to dobre, bo lamiac jedno takie haslo mamy dostep do wszystkich kont z tym samym hashem. Dlatego ja stosuje cos w rodzaju sha( 'jakis_ciag' + sha(haslo)), gdzie 'jakis_ciag' to jest jakis string wygenerowany w jakis sposob z danych tego uzytkownika (musi byc za kazdym razem taki sam, zeby za kazdym razem byl generowany taki sam hash).
W najprostszej wersji moze to byc chociazby sam login (albo nawet jego hash, zeby za latwo nie bylo ;]) lub tez jakas inna kombinacja niezmienialnych danych o uzytkowniku.

[kszychu]

Na przyklad po to o czym napisales w pogrubionym akapicie. Majac haslo danej osoby mozna sprobowac tym samym haslem wejsc na jakies inne serwisy, w ktorych jest ona zarejestrowana.. kto wie czy ludzie nie daja takich samych hasel do maila, na ktorego sie zarejestrowali, a majac baze prawdopodobnie jestesmy w ich posiadaniu, a to juz cos.

Dlatego napisałem, że tylko głupcy używają tego samego hasła do róznych rzeczy.

[FiDO]

Ja tak robie (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Oczywiscie nie ot tak sobie przypadkowo.. mam zestaw kilku hasel o zroznicowanym stopniu skomplikowania oraz kilka ich wariacji (rozniacych sie z reguly kilkoma znakami). Uzywam ich zgodnie ze stopniem waznosci danego konta, wiec rzeczy najwazniejsze maja te najtrudniejsze hasla (nawet i ok 25 znakow), a rzeczy o najnizszym priorytecie maja te prostsze (i w sumie tylko te hasla i ich wariacje sie powtarzaja).
Gdybym mial wymyslac osobne haslo do kazdego konta to mialbym problem z ich zapamietaniem. A w ten sposob hasel "glownych" mam dosc malo, pamietam wszystkie ich wariacje, wiec w sumie mam do dyspozycji kilkanascie roznych kombinacji. O ile hasel raczej nie zapominam to zdarza mi sie czasem zapomniec, ktore uzywam do jakiegos tam rzadko uzywanego konta. Jakbym mial ich wiecej to sprawa by sie jeszcze skomplikowala, a zapisywac hasel na dysku (czy innej pamieci zewnetrznej w stosunku do glowy) nie mam zamiaru (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[shpyo]

md5 da się odhaszować.
http://md5.rednoize.com/
Więc lepiej używać sha1

sha1 to już przeszłość - został złamany przez dwie Chinki.

[UsTeK]

sha1 to już przeszłość - został złamany przez dwie Chinki.

A co to znaczy że został złamany? Znaleziono kolizję? W takim razie kiedy złamano MD5? Dlaczego więc nadal używa się MD5?

Moja propozycja to:

[PHP] pobierz, plaintext 
<?php
$pass = md5( sha1($_POST['pass']) . $_POST['pass'] );
?>
[PHP] pobierz, plaintext 

//Edit:
Sorrki, głupote walnąłem, miało być na odwrót:

[PHP] pobierz, plaintext 
<?php
$pass = sha1( md5($_POST['pass']) . $_POST['pass'] );
?>
[PHP] pobierz, plaintext 

Dlaczego tak? B-F dla sha1 jest o wiele mniej popularny, a dodanie md5($_POST['pass']) sprawia, że RainbowTable jest bezużyteczny.



Pozdrawiam,
UsTeK

Ten post edytował UsTeK 3.04.2006, 18:53:59

[Vengeance]

Dlaczego twierdzicie, że n-hash kompletnie nic nie daje? Wg mnie, przy metodzie brute-force zwiększa czas potrzebny na pozyskanie hasła (i to do czasu wrecz nieosiagalnego dla nas... kilkadziesial latek).

Może uzasadnie jak to widze (jesli sie myle poprawcie):
Jezeli uzytkownik zakoduje haslo 'test' metoda brute-force sprawdzajaca po kolei alfabet dosc szybko zwroci wynik. Ale przy podwojnym hashu, najpierw trzeba bedzie odgadnac 1 hash, a dopiero potem realne hasło. Biorac pod uwage, jak ciezej jest trafic w 32 znakowe haslo (w stosunku do tego 4 znakowego) chyba nikt mi nie powie, ze 2xmd5 jest bezsensu?

Ja to traktuje jako zwykle "wzmocnienie" hasla uzytkownika. Z takieog 4 znakowego na 32...

[nospor]

Jezeli uzytkownik zakoduje haslo 'test' metoda brute-force sprawdzajaca po kolei alfabet dosc szybko zwroci wynik. Ale przy podwojnym hashu, najpierw trzeba bedzie odgadnac 1 hash, a dopiero potem realne hasło. Biorac pod uwage, jak ciezej jest trafic w 32 znakowe haslo (w stosunku do tego 4 znakowego) chyba nikt mi nie powie, ze 2xmd5 jest bezsensu?

Przy metodzie brute force, generuje się hasla, anie hashe. potem te haslo wysyla się na serwer lub tez wykonuje te samo hashowanie co na serwerze. Tak wiec dla b-f bez roznicy jest przez co to haslo zostanie zmielone, gdyz generujemy hasla a nie kolejne kroki mielenia.
Te kolejne hashe, mogą wydluzyc czas znalezienia hasla metodą b-f, gdyż trzeba dodatkowo x -razy wywolac te md5, ktore jakis tam czas sie wykonuje.

Ja osobiscie juz troche inaczej patrze na to mieszanie hashy, ale to tylko ze względu na te slowniki co juz w necie są

[popo]

2xmd5 = 2x wieksza szansa na kolizje.
Z prostego powodu, ze md5 jest stratny.
Istnieje wiec realna szansa, ze pomimo podania 2 roznych hasel mozesz dostac ten sam hasz 2 poziomu.
Jesi haszujesz md5 to wlamywacz nie musi wcale szukac oryginalnego tekstu, a jedynie cos co da mu klucz 1 poziomu. Jak juz to cos znajdzie to hasz 2 poziomu sam sie wygeneruje identycznie jak dla poprawnego hasla.
Poza tym nie musi on trafic w idealnie ten sam hasz 1 poziomu a jedynie w jeden z wielu ktore dadza mu w rezultacie hasz 2 poziomu co w rezultacie znacznie zwieksza szanse na trafienie.

Zagniezdrzanie md5 samego w sobie nie jest raczej dobrym pomyslem, zreszta zagnierzdzanie jakiegokolwiek "haszowania" nie jest polecane (zwieksza sie strate informacji, a co za tym idzie zwieksza prawdopodobienstwo trafienia w "kolizje")

Mozna oczywiscie zastosowac inne algorytmy szyfrowania, ale to raczej malo ekonomiczne i jak ktos wlamie sie na serwer, to i tak za wiele nie da bo bedzie mogl sobie obejrzec algorytm szyfrujacy. Chyba ze umiescimy go poza obszarem dostepnym z internetu, czyli wwwroot. W wielu serwisach udostepniajacych uslugi hostingowe moze to jednak stanowic powazny problem.

co do nieslabnacej popularnosci md5 to ... niestety na wielu serwerach nie ma mozliwosci uzywania sha1 (znam conajmniej 2 takie i to platne)
Tam, zmuszony jestes stosowac md5

Pewnym pomyslem moze byc dodawanie jakiegos dodatkowego ciagu do hasel userow tyle, ze problem taki sam jak poprzednio w razie zlamania zabezpieczen wlamywacz najprawdopodobniej bedzie mogl sobie podejrzec ten ciag

Najlepszym wiec sposobem na zabespieczenie userow jest uswiadomienie im jak wazne jest wybranie odpowiednio dlugiego i trudnego do odganiecia hasla.

Mozna tez stosowac wstepne sprawdzanie hasel proponowanych przez userow i poprostu odrzucac te zbyt proste lub oczywiste (cos na wzor cracklib uzywanego do eliminowania slabych hasel userow przy ich zmianie dla kont shelowych)

Jest to oczywiscie utrudnieniem dla uzytkownikow i nie zawsze mozna stosowac tego typu praktyki

[Vengeance]

Tak wiec dla b-f bez roznicy jest przez co to haslo zostanie zmielone, gdyz generujemy hasla a nie kolejne kroki mielenia.

Ja mówiłem o najczęstrzej sytuacji... gdzie ktoś np. uzyskuje dostęp do bazy sql czy też w jakiś inny sposób poznaje hash hasła użytkownika. W tym momencie, odgadniecie hasla metoda bruteforce przy dwukrotnym hashu jest bedzie duzo trudniejsze!

"2xmd5 = 2x wieksza szansa na kolizje." Przykro mi, że nie mam tak potężnej wiedzy w kryptografii, iż nie mogę tego ani poprzezć ani obalić. Ale na "mój nos" mogę powiedzieć, że nigdy się z tobą nie zgodzę w tej kwestii (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Powracając znów do wypowiedzi nospora, jeżeli mówimy o metodzie b-f na zasadzie: wyślij formularz POST do skryptu logowanie.php to i najlepsze alg. nic nie poradzą :] Powótrze jeszcze raz, ja mówie o sytuacji gdzie ktoś w jakiś sposób zdobywa 32 znaki z zakresu 0-9a-f :]

[nospor]

Ja mówiłem o najczęstrzej sytuacji... gdzie ktoś np. uzyskuje dostęp do bazy sql czy też w jakiś inny sposób poznaje hash hasła użytkownika. W tym momencie, odgadniecie hasla metoda bruteforce przy dwukrotnym hashu jest bedzie duzo trudniejsze!

Powracając znów do wypowiedzi nospora, jeżeli mówimy o metodzie b-f na zasadzie: wyślij formularz POST do skryptu logowanie.php to i najlepsze alg. nic nie poradzą :] Powótrze jeszcze raz, ja mówie o sytuacji gdzie ktoś w jakiś sposób zdobywa 32 znaki z zakresu 0-9a-f :]

Nie, no oczywiscie, jezeli ktos zdobedzie hasha i mysli ze ten hash powstal w wyniku jednokrotnego uzycia md5, to i faktycznie nie znajdzie metodą b-f hasla, gdy bedzie tylko raz przepuszczal przez md5. Ale jezeli ten ktos, wie, ze to bylo dwa razy md5, to na nic to, ze to bylo dwa razy md5. Takie samo zabezpieczenia co by bylo tylko raz. Przeciez wowczas hacker wie, jak ma mielic do b-f (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[Vengeance]

"Ale jezeli ten ktos, wie, ze to bylo dwa razy md5, to na nic to, ze to bylo dwa razy md5. Takie samo zabezpieczenia co by bylo tylko raz."

Wiesz ile setek lat by trwało "trafienie" w 32 znakowy hash, który wygenerował ten drugi hash? (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) Także uważam, że 2xHash (czy jakie kolwiek inne sposoby na dodawanie smieci do hasla usera zanim je zahashujemy) ma sens.

[nospor]

widze że się nie rozumiemy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

koles gdy robi b-f, generuje hasla w postaci jawnej, a nie hashe. I skoro wie, jak je potem mielic, to dla niego juz bez roznicy, czy raz md5 czy dwa razy, gdyż niezależnie od tego on generuje hasla. Czas jaki się zwiększy na znalezienie hasla, to tylko o te dodatkowe jedno wykonanie funkcji md5() (oczywiscie w petli).

[Vengeance]

No tak racja, o ile wie ;] Najczęściej nie wie i skapnie się dopiero po 150x latach, gdy w rezultacie otrzyma 32 znakowe hasło (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif)

[popo]

Vengance on nawet nie musi tego wiedziec cala brudna robote odwala za niego twoje wlasne skrypty (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) btw moja opinia oparta jest o raczej dobrze poinformowane zrodla, a co do wyciagania z hashy hasel to erm nie musi zgadnac jedynego poprawnego wystarczy ze znajdzie cos co daje taki hash a jesli wlamie sie na twoje konto na serwerze to pewnikiem zdola przejrzec skrypty a wtedy no cuz (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
dodawanie jakichs losowych ciagow do hasel ma sens ale nie zawsze (jesli masz mozliwosc ukryc totalnie przed dostepem z zewnatrz to cos co dodajesz to ok zwiekszy dlugosc hasla i cos co zostanie zdekodowane z hasza wprowadzone na stronce nie zadziala, jednak nie daje to zadnej ochrony porzed atakami z sieci na twoj serwis typu brute force najlepiej przed tym chronia te "powszechnie lubiane obrazki z koslaymi niewyraznymi losowymi literkami i cyferkami (nie widzialem jeszcze automatu ktory by to potrafil ominac)

[Vengeance]

Te obrazki zwą sie "captcha" i sa automaty je odczytujące (ofc nie wszystkie).
Jest nawet stronka/projekt w necie skupiająca programistów tworzących czytniki takowych.

Swego czasu anakin napisał skrypt w php! o 100% skuteczności odczytywania takich obrazków przy rejestracji w GaduGadu - to dlatego 3 dni potem zostały one zmienione na takie jak te widoczne dziś (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[Kuziu]

~Vengeance Zrób taki mały test:

Zakoduj sobie np. 'fgfwe34r3ferg45twerg' ... czyli obojętnie jaki ciąg którego

http://md5.rednoize.com/

Nie pozna

a potem zrób to samo z słowa którego nie poznało.

Będziesz miał jasną odpowiedź.

Łatwiej im było zrobić wszystki 32 znakowe ciągki z zakresu a-f-1-9 zrobić B-F niż wszystkie pozostałe ciągi.

Więc gdy bym dostał ten Twój 2xmd5 to w moment bym go mial a normalnego gerg345r38jv934 bym tak szybko nie dostał

[chomiczek]

trochę odświeże temat:
http://www.stachliu.com/collisions.html pod tym adresem jest do pobrania programik, który potrafi w ciągu kilkudziesięciu minut na domowym PC wygenerować kolidujący z podanym skrót MD5.

Dodatkowo na plus za SHA-1 przemawia fakt, że funkcja ta jest standardem wykorzystywanym przez agencje rządowe Stanów Zjednoczonych Ameryki Północnej.

[thornag]

Odswierzam troche temat ale mysle ze moje pytanie najlepiej pasuje wlasnie do tego,

Kod

md4 md5 sha1 sha256 sha384 sha512 ripemd128 ripemd160 whirlpool tiger128, 3 tiger160, 3 tiger192, 3 tiger128, 4 tiger160, 4 tiger192, 4 snefru gost adler32 crc32 crc32b haval128, 3 haval160, 3 haval192, 3 haval224, 3 haval256, 3 haval128, 4 haval160, 4 haval192, 4 haval224, 4 haval256, 4 haval128, 5 haval160, 5 haval192, 5 haval224, 5 haval256, 5

To sa algorytmu mieszajace dostepne u mnie na serwerze. Wszedzie slysze tylko o md5 i sha1, co mozecie powiedziec o reszcie ? Sa przestarzale ? Niezbyt bezpieczne ? Dlaczego zamiat sha1 nie stosowac sha256, string jest dluzszy, fakt faktem zajmuje zdecydowanie wiecej miejsca ale i ryzyko kolizji jest chyba mniejsze. Co z pozostalymi ? Dlaczego taie jak haval, tiger czy whirlpool sa tak malo popularne ?

[MajareQ]

md5 da się odhaszować.
http://md5.rednoize.com/
Więc lepiej używać sha1

czy to przypadkiem nie jest jedna z teczowych tablic?

[kwiateusz]

cos w ten desen ale przy 12 znakach nie znalazł hasha (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) bardzo wybrakowane te tablice np nie łamie hasha zbudowanego w oryginale z ciagu cyfr

[MajareQ]

jednym słowem jeszcze daleko brakuje do łamacza hashów z prawdziwego zdarzenia...

[pinochet]

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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) oczywiście mądry hacker od razu sprawdzi 1-hashowanie i 2-hashowanie dlatego ja również polecam dodawanie do hasła tajnego ciągu i np loginu.
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

[Zyx]

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ć (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) . W każdym razie otrzymujemy wtedy równość: H(H( A )) = H(H( B )) = H(H( C )) = H(H( D )), tak więc gdy wygenerujemy hasło "A", ono zostanie zaakceptowane nawet, jeśli oryginał brzmi "C" i jeśli po pojedynczym zahaszowaniu takie coś by nie weszło. Nie zachodzi za to sytuacja w drugą stronę, tj. jeśli A i B kolidują, to po podwójnym zahaszowaniu dalej będą kolidować. Wniosek: wielokrotne haszowanie pogasza sprawę tym bardziej, im więcej razy złożymy naszą funkcję z samą sobą.

Ten post edytował Zyx 14.10.2008, 07:21:44

[pinochet]

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

[Zyx]

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

[pinochet]

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 (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) Hyba nie bo znając hasha: f:X-> {a}, aby poznać hasło jawne musimy poznać cały zbiór X (przynajmniej teoretycznie).

[Michu]

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

[mike]

Słabość MD5 polega na tym że wszyscy znają ten algorytm, dlatego teorytycznie da się go 'odhashować'.

Tyle wałkowania i na darmo.
W jednym zdaniu poinformowałeś nas, że nie znasz md5. Bo jego nie da się "odhaszować". To nie jest algorytm dwustronny (IMG:http://forum.php.pl/style_emoticons/default/exclamation.gif) (IMG:http://forum.php.pl/style_emoticons/default/exclamation.gif)

[michalkjp]

@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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[Zyx]

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) (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

Ten post edytował Zyx 18.10.2008, 22:22:10

[michalkjp]

Obecnie znane są metody, które pozwalają na znalezienie kolizji na domowym pececie w parę godzin.

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

[Zyx]

Ech, wystarczy w Google wpisać "MD5 collisions" i masz tyle źródeł, że głowa boli (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

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.

[Kicok]

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:

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

Kod

md5( md5( dupa8 ) ) == 7878787878
md5( 112ó&#0GHG:s\ ) == 7878787878

ALE:
md5( md5( 112ó&#0GHG:s\ ) ) == 9090909090

7878787878 != 9090909090
md5( md5( dupa8 ) ) != md5( md5( 112ó&#0GHG: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

[Zyx]

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?

[mike]

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 (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)
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ść.

[Kicok]

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

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

[nospor]

Po potraktowaniu tego hasha brute-forcem

Brute force wykonuje sie zazwyczaj na aplikacji, wiec aplikacja bedzie przepuszczala to przez podwojne hashowanie (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[Kicok]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
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

[312]

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

[Zyx]

Ź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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) . 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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

[Apocalyptiq]

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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[phpion]

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

[Apocalyptiq]

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

Kod

$start = microtime();
for($a=0;$a<100;$a++){
     echo $a,': ',hash('sha256',hash('md5',uniqid(mt_rand(0,1000000000),true))),'<br/>';
}
$koniec = microtime();
echo 'Strona wygenerowana w '.($koniec - $start).' sekund';

Czas wygenerowania takiego czegoś - około 0,01s (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował Apocalyptiq 22.11.2008, 11:32:57

[phpion]

Ja wiem czy duże obciążenie serwera? Przeprowadziłem mały test:
Czas wygenerowania takiego czegoś - około 0,01s (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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

Kod

Rendered in 0.0294 seconds

[Apocalyptiq]

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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) 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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) ), 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? (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)
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.

[Crozin]

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

[marcio]

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.

[phpion]

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

[marcio]

Mowi sie trudno (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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.

[Apocalyptiq]

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

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

[bełdzio]

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

[Zyx]

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.

[luki100011]

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.

[Crozin]

Można by sie teraz pokusić o hashowanie hasła na innym serwerze.

A to wiąże się z koniecznością przesłania tego hasła - czyli kolejna potencjalna bramka do haseł.

Czyli równie dobrze można nie kodować 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.

[pinochet]

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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) 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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) 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.

[Wykladowca]

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

[Pilsener]

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

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

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

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

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

[Caus]

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

Ten post edytował Caus 8.02.2009, 05:18:47

[KaveS]

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

[Crozin]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[Mikz]

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 (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) ) 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ć (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) . Pytanie pewnie pojawi się, jak przy tym cholerstwie napisać funkcję porównującą hasło z hashem, skoro hash jest losowy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ?
Sprawa jest prosta:

Kod

$hasloZahashowane = //Tu wciskamy zahashowany wcześniej przez crypt() ciąg
$password = crypt($hasloWprowadzonePrzezUsera, $hasloZahashpwane);
      
if ($password == $hasloZahashowane)
{    
  //zalogowano
}    
else
{
  //nie zalogowano
}

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

[.radex]

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.

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.

Ten post edytował .radex 21.02.2009, 15:29:46

[MWL]

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

[Zyx]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

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:

Kod

sha1($zrodloweHaslo . ($sol = generatorSoli()));

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ś (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[Mikz]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

[fernet]

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

[Kocurro]

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.

[guitarnet.pl]

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

[Crozin]

troche wyobrazni paniowie...

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

[Apocalyptiq]

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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) 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?

[sowiq]

Możnaby ewentualnie dla każdego hashowanego hasła ustalać inny klucz, np. losowy

Wspaniały pomysł. Tylko taki losowy klucz też chyba gdzieś musisz mieć zapisany? A gdzie go zapiszesz jak nie w bazie danych? (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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)

Ten post edytował sowiq 4.06.2009, 14:39:55

[Apocalyptiq]

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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) 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)?

[sowiq]

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ą

Poczytaj o kolizjach.

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

Ja mam taki projekt na Programowanie Równoległe i Rozproszone. Ściślej odpowiem jak go zrobię (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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ę.

Ten post edytował sowiq 4.06.2009, 15:01:39

[Apocalyptiq]

Poczytaj o kolizjach.

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

[sowiq]

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źć (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował sowiq 4.06.2009, 15:46:48

[Apocalyptiq]

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źć (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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.

Ten post edytował Apocalyptiq 5.06.2009, 10:35:31

[sowiq]

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

Jeśli pracujesz dla Amerykańskiej armii i ochraniasz hasłem 'red button', to tak (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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.

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował sowiq 5.06.2009, 11:20:27

[Apocalyptiq]

Jeśli pracujesz dla Amerykańskiej armii i ochraniasz hasłem 'red button', to tak (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) 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ł :-)

Ten post edytował Apocalyptiq 5.06.2009, 13:34:05