Drukowana wersja tematu

Kliknij tu, aby zobaczyć temat w orginalnym formacie

Forum PHP.pl _ PHP _ podwójne hashowanie haseł

Napisany przez: nospor 27.02.2006, 11:48:23

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

Napisany przez: wijet 27.02.2006, 14:09:17

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

  1. <?php
  2.  
  3. $tajny_ciag = '23mjdkifjS1lpo321lpSAo5c90sawe3';
  4.  
  5. $zaszyfrowane = http://www.php.net/md5($tajny_ciag.http://www.php.net/md5($tajny_ciag.$_POST['pass']));
  6.  
  7. ?>

Napisany przez: mike_mech 27.02.2006, 14:30:17

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

Napisany przez: FiDO 22.03.2006, 18:47:42

Cytat(mike_mech @ 2006-02-27 14:30:17)
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 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 winksmiley.jpg

Napisany przez: rbart 22.03.2006, 20:27:09

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

Napisany przez: sopel 22.03.2006, 23:26:40

Cytat(nospor @ 2006-02-27 11:48:23)
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 winksmiley.jpg Moze się okazać, ze podwojne shashowanie hasla, zostanie rozwiązane szybciej, niż byś to zrobil tylko raz smile.gif tak więc nie kombinuj 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 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 tongue.gif

Napisany przez: Aztech 23.03.2006, 00:31:50

[offtopic mode on]

Cytat
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

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

Napisany przez: nospor 23.03.2006, 08:34:33

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

Napisany przez: lenzcewski 23.03.2006, 18:34:57

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

Cytat
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

winksmiley.jpg istnieje jeszcze coś takiego na kolizje kodowania, tzn. 32 znaki muszą się kiedyś powtarzać, dlatego jeżeli będziesz chciał coś "odkompresować" 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 winksmiley.jpg złamanie takiego hasła (przeszukanie bazy) to ok. 3 min.

-edyta:
jeszcze raz [OT]:
Cytat
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.

Napisany przez: My4tic 23.03.2006, 21:02:40

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.

Napisany przez: nospor 23.03.2006, 21:10:40

Kurka wodna, jak to potrafią czlowiekowi wodę z mózgu zrobić.... winksmiley.jpg
Jak tak czytam kolejne wypowiedzi, to zaczynam wierzyć w lekki sens tego kombinowania 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

Napisany przez: My4tic 23.03.2006, 21:23:26

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

http://gdataonline.com/seekhash.php

to już bedzie problem.

Napisany przez: lenzcewski 23.03.2006, 22:48:20

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 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 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 ;(

Napisany przez: SHiP 23.03.2006, 23:02:10

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 ;]

Napisany przez: lenzcewski 24.03.2006, 06:53:32

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

Napisany przez: chomiczek 24.03.2006, 09:04:19

Cytat(SHiP @ 2006-03-23 22:02:10)
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źć.

Napisany przez: lenzcewski 24.03.2006, 09:23:34

http://www.hakin9.org/pl/attachments/md5_pl.pdf
http://www.stachliu.com/collisions.html
http://www.google.com/search?client=opera&rls=pl&q=kolizje+md5&sourceid=opera&ie=utf-8&oe=utf-8

Napisany przez: kszychu 24.03.2006, 10:59:10

Cytat(lenzcewski @ 2006-03-24 06:53:32)
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.

Napisany przez: E-d 24.03.2006, 11:36:29

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

Napisany przez: lenzcewski 24.03.2006, 11:41:30

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?

Napisany przez: nospor 24.03.2006, 11:58:22

Cytat
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 winksmiley.jpg Ale spora grupa osób tak robi.

Podobnie jest tutaj. Chcemy miec bezpieczne hasla? Zadbajmy oto sami smile.gif
Oczywiście jesli i dany serwis nam w tym pomoże, to też nie zaszkodzi winksmiley.jpg

ps: mojego hasla nie zlamal biggrin.gif

Napisany przez: kszychu 24.03.2006, 12:28:06

Cytat(lenzcewski @ 2006-03-24 11:41:30)
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ł?

Cytat
http://md5.rednoize.com/

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

Napisany przez: FiDO 24.03.2006, 13:23:39

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

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

Napisany przez: kszychu 24.03.2006, 14:04:57

Cytat(FiDO @ 2006-03-24 13:23:39)
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.

Napisany przez: FiDO 24.03.2006, 17:00:16

Ja tak robie 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 smile.gif

Napisany przez: shpyo 24.03.2006, 23:46:19

Cytat(E-d @ 2006-03-24 12:36:29)
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.

Napisany przez: UsTeK 3.04.2006, 18:05:51

Cytat
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:
  1. <?php
  2. $pass = http://www.php.net/md5( sha1($_POST['pass']) . $_POST['pass'] );
  3. ?>



//Edit:
Sorrki, głupote walnąłem, miało być na odwrót:
  1. <?php
  2. $pass = sha1( http://www.php.net/md5($_POST['pass']) . $_POST['pass'] );
  3. ?>

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



Pozdrawiam,
UsTeK

Napisany przez: Vengeance 3.04.2006, 19:17:35

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

Napisany przez: nospor 3.04.2006, 19:31:41

Cytat
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ą

Napisany przez: popo 3.04.2006, 20:03:29

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

Napisany przez: Vengeance 3.04.2006, 21:36:24

Cytat
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 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 :]

Napisany przez: nospor 3.04.2006, 21:43:26

Cytat
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 smile.gif

Napisany przez: Vengeance 3.04.2006, 21:49:30

"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? biggrin.gif Także uważam, że 2xHash (czy jakie kolwiek inne sposoby na dodawanie smieci do hasla usera zanim je zahashujemy) ma sens.

Napisany przez: nospor 3.04.2006, 22:07:15

widze że się nie rozumiemy 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).

Napisany przez: Vengeance 3.04.2006, 22:09:57

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

Napisany przez: popo 3.04.2006, 22:44:57

Vengance on nawet nie musi tego wiedziec cala brudna robote odwala za niego twoje wlasne skrypty 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 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)

Napisany przez: Vengeance 3.04.2006, 22:58:49

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ś winksmiley.jpg

Napisany przez: Kuziu 3.04.2006, 23:03:47

~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ł

Napisany przez: chomiczek 18.04.2006, 08:33:09

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.

Napisany przez: thornag 6.11.2006, 17:34:16

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 ?

Napisany przez: MajareQ 4.02.2008, 20:33:41

Cytat(E-d @ 24.03.2006, 11:36:29 ) *
md5 da się odhaszować.
http://md5.rednoize.com/
Więc lepiej używać sha1



czy to przypadkiem nie jest jedna z teczowych tablic?

Napisany przez: kwiateusz 5.02.2008, 20:43:02

cos w ten desen ale przy 12 znakach nie znalazł hasha smile.gif bardzo wybrakowane te tablice np nie łamie hasha zbudowanego w oryginale z ciagu cyfr

Napisany przez: MajareQ 6.02.2008, 21:07:06

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

Napisany przez: pinochet 9.10.2008, 12:58:45

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

Napisany przez: Zyx 14.10.2008, 07:20:42

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

Napisany przez: pinochet 14.10.2008, 20:43:50

Cytat(Zyx @ 14.10.2008, 08:20:42 ) *
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.
Cytat(Zyx @ 14.10.2008, 08:20:42 ) *
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 ...

Napisany przez: Zyx 16.10.2008, 09:43:20

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.

Napisany przez: pinochet 16.10.2008, 18:03:43

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

Napisany przez: Michu 16.10.2008, 18:34:21

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

Napisany przez: mike 16.10.2008, 21:32:13

Cytat(Michu @ 16.10.2008, 19:34:21 ) *
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 exclamation.gif exclamation.gif

Napisany przez: michalkjp 16.10.2008, 22:01:15

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

Napisany przez: Zyx 18.10.2008, 22:15:38

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

Napisany przez: michalkjp 18.10.2008, 22:26:13

Cytat(Zyx @ 18.10.2008, 23:15:38 ) *
Obecnie znane są metody, które pozwalają na znalezienie kolizji na domowym pececie w parę godzin.

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

Napisany przez: Zyx 19.10.2008, 10:52:23

Ech, wystarczy w Google wpisać "MD5 collisions" i masz tyle źródeł, że głowa boli 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.

Napisany przez: Kicok 20.10.2008, 18:36:32

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

1. md5( HASLO )

  1. <?php
  2.  
  3.    $login = http://www.php.net/mysql_real_escape_string( $_POST['login'] );
  4.    $haslo = $_POST['haslo'];
  5.  
  6.    $haslo = http://www.php.net/md5( $haslo );
  7.  
  8.    $result = http://www.php.net/mysql_query( "SELECT * FROM users WHERE login = '$login' AND haslo = '$haslo'" ) or http://www.php.net/die( http://www.php.net/mysql_error() );
  9.    if( http://www.php.net/mysql_num_rows( $result ) )
  10.    {
  11.        // ZALOGOWANY
  12.    }
  13.  
  14. ?>


2. md5( HASLO + SÓL )
  1. <?php
  2.  
  3.    http://www.php.net/define( 'SALT', '#@r23T@f23NJOąąąĆóŁd;'[:""{:ffs+SD:+@wD#~`ds2' );
  4.  
  5.  
  6.    $login = http://www.php.net/mysql_real_escape_string( $_POST['login'] );
  7.    $haslo = $_POST['haslo'];
  8.  
  9.    $haslo = http://www.php.net/md5( $haslo . SALT );
  10.  
  11.    $result = http://www.php.net/mysql_query( "SELECT * FROM users WHERE login = '$login' AND haslo = '$haslo'" ) or http://www.php.net/die( http://www.php.net/mysql_error() );
  12.    if( http://www.php.net/mysql_num_rows( $result ) )
  13.    {
  14.        // ZALOGOWANY
  15.    }
  16.  
  17. ?>


3. md5( md5( HASLO ) )
  1. <?php
  2.  
  3.    $login = http://www.php.net/mysql_real_escape_string( $_POST['login'] );
  4.    $haslo = $_POST['haslo'];
  5.  
  6.    $haslo = http://www.php.net/md5( http://www.php.net/md5( $haslo ) );
  7.  
  8.    $result = http://www.php.net/mysql_query( "SELECT * FROM users WHERE login = '$login' AND haslo = '$haslo'" ) or http://www.php.net/die( http://www.php.net/mysql_error() );
  9.    if( http://www.php.net/mysql_num_rows( $result ) )
  10.    {
  11.        // ZALOGOWANY
  12.    }
  13.  
  14. ?>



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.

Napisany przez: Zyx 21.10.2008, 07:12:07

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?

Napisany przez: mike 21.10.2008, 08:54:12

Cytat(Kicok @ 20.10.2008, 19:36:32 ) *
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 tongue.gif
Spójrz co piszesz:
Cytat(Kicok @ 20.10.2008, 19:36:32 ) *
- Stosowanie (...) podwójnego hashowania jest bezpieczniejsze niż zwykłe pojedyncze hashowanie md5
Cytat(Kicok @ 20.10.2008, 19:36:32 ) *
(...) 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.

Cytat(Zyx @ 21.10.2008, 08:12:07 ) *
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ść.

Napisany przez: Kicok 21.10.2008, 10:43:30

Cytat("mike")
Oczywiście że jest błędne. Jest po prostu sprzeczne, więc nawet nie ma co się wyslilać żeby pokazać błąd
Spójrz co piszesz:
Cytat("Kicok")
- Stosowanie (...) podwójnego hashowania jest bezpieczniejsze niż zwykłe pojedyncze hashowanie md5

Cytat("Kicok")
(...) tworzenie potworków w stylu: md5( md5( md5( md5( md5( md5( md5( md5( md5( md5( dupa8 ) ) ) ) ) ) ) ) ) ) jest kompletnie bezcelowe.

Raz twierdzisz co innego a później cos innego. Zdecyduj się co chcesz pokazać.

Tak w skrócie to napisałem powyżej:
- Stosowanie 2-krotnego hashowania jest bezpieczniejsze niż pojedyńcze hashowanie
- Stosowanie 50-krotnego hashowania jest tak samo bezpieczne, jak 2-krotne hashowanie, więc stosowanie potworków typu: md5( md5( md5( md5( md5( dupa8 ) ) ) ) ) jest bezcelowe (w domyśle: można stosować po prostu md5( md5( dupa8 ) ) )

Ja tu nie widzę żadnej sprzeczności.


Cytat("mike")
Tak czy inaczej wielokrotne (dwa to też więcej niż jeden) haszowanie nie ma sensu.

Załóżmy, że md5( md5( dupa8 ) ) jest równe 1212121212. Po potraktowaniu tego hasha brute-forcem otrzymamy kolizję q@w#E$5.
Po wpisaniu tego w formularzu znowu wykonywane jest podwójne hashowanie: md5( md5( q@w#E$5 ) ), ale logowanie nie powiedzie się, ponieważ hash w tym przypadku NIE JEST równy 1212121212. BYŁBY, gdybyśmy zrobili samo: md5( q@w#E$5 ).
Jeśli łotr zorientowałby się, że zastosowano podwójne hashowanie, musiałby:
a.) odnaleźć kolizję z zakresu 0x00000000000000000000000000000000 - 0xffffffffffffffffffffffffffffffff (w najrogszym wypadku 16^32 prób)
b.) odnaleźć kolizję kolizji

LUB
a.) skorzystać z tęczowych tablic, jeśli rzeczywiście są one tak rozbudowane, że przechowują także hashe hashy. W takim przypadku faktycznie podwójne hashowanie nie zwiększa praktycznie w ogóle poziomu bezpieczeństwa.


EDIT
PS1. Oczywiście jeśli kolizje haseł hashowanych podwójnie można odczytać z tęczowych tablic, to stwierdzenie, że 50-krotne hashowanie jest tak samo silne jak 2-krotne jest nieprawdziwe
PS2. Nadal podtrzymuję prośbę, żeby mi ktoś łopatologicznie wyjaśnił dlaczego się mylę twierdząc, że podwójne hashowanie jest bezpieczniejsze niż pojedyńcze. Bo jak na razie została mi wytknieta sprzeczność tam, gdzie jej nie widzę oraz zostałem ochrzaniony za to, że nie wiedziałem, że w tęczowych tablicach są hashe hashów.
PS3. Skoro jednak są hashe hashów w tęczowych tablicach, to czy potrójne hashowanie jest bezpieczniejsze niż pojedyńcze? A jeśli w tęczowych tablicach są też hashe hashów hashów, to ile gigabajtów zajmuje taka tablica (dla haseł alfanumerycznych 1-8 znakowych )?

Napisany przez: nospor 21.10.2008, 10:46:56

Cytat
Po potraktowaniu tego hasha brute-forcem
Brute force wykonuje sie zazwyczaj na aplikacji, wiec aplikacja bedzie przepuszczala to przez podwojne hashowanie smile.gif

Napisany przez: Kicok 21.10.2008, 11:02:22

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

Napisany przez: 312 14.11.2008, 09:17:00

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

Napisany przez: Zyx 17.11.2008, 10:21:47

Ź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 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 smile.gif.

Napisany przez: Apocalyptiq 21.11.2008, 21:53:22

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

Napisany przez: phpion 21.11.2008, 21:58:24

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

Napisany przez: Apocalyptiq 22.11.2008, 11:31:58

Cytat(phpion @ 21.11.2008, 21:58:24 ) *
@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 smile.gif

Napisany przez: phpion 22.11.2008, 11:35:12

Cytat(Apocalyptiq @ 22.11.2008, 13:31:58 ) *
Ja wiem czy duże obciążenie serwera? Przeprowadziłem mały test:
Czas wygenerowania takiego czegoś - około 0,01s smile.gif

Dla porównania:
http://kohanaphp.com/home
Kod
Rendered in 0.0294 seconds

Napisany przez: Apocalyptiq 22.11.2008, 13:33:15

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

Napisany przez: Crozin 23.11.2008, 11:04:51

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

Napisany przez: marcio 23.11.2008, 11:32:13

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.

Napisany przez: phpion 23.11.2008, 11:34:45

Cytat(marcio @ 23.11.2008, 13:32:13 ) *
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ę...

Napisany przez: marcio 23.11.2008, 11:51:02

Mowi sie trudno 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.

Napisany przez: Apocalyptiq 2.12.2008, 08:39:10

Cytat(Crozin @ 23.11.2008, 11:04:51 ) *
Żeby hash hasła trzymać w cookie... trzeba być naprawdę geniuszem.


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

Napisany przez: bełdzio 2.12.2008, 12:27:07

Cytat(Apocalyptiq @ 2.12.2008, 08:39:10 ) *
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

Napisany przez: Zyx 2.12.2008, 12:53:36

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.

Napisany przez: luki100011 5.01.2009, 22:25:09

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.

Napisany przez: Crozin 5.01.2009, 22:58:40

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

Napisany przez: pinochet 5.01.2009, 23:25:34

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

Napisany przez: Wykladowca 19.01.2009, 13:24:49

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

Napisany przez: Pilsener 26.01.2009, 12:27:18

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

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

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

Napisany przez: Caus 8.02.2009, 05:14:44

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

Napisany przez: KaveS 21.02.2009, 07:51:17

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

Napisany przez: Crozin 21.02.2009, 11:41:33

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

Napisany przez: Mikz 21.02.2009, 14:25:26

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 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ć tongue.gif. Pytanie pewnie pojawi się, jak przy tym cholerstwie napisać funkcję porównującą hasło z hashem, skoro hash jest losowy 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

Napisany przez: .radex 21.02.2009, 15:17:42

Cytat(Wykladowca @ 19.01.2009, 13:24:49 ) *
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.

Napisany przez: MWL 25.02.2009, 13:34:59

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

Napisany przez: Zyx 26.02.2009, 21:23:18

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 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ś tongue.gif

Napisany przez: Mikz 12.03.2009, 13:56:06

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

Napisany przez: fernet 21.04.2009, 19:35:13

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

Napisany przez: Kocurro 21.04.2009, 19:40:45

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.

Napisany przez: guitarnet.pl 21.04.2009, 19:54:44

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

Napisany przez: Crozin 21.04.2009, 21:47:28

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

Napisany przez: Apocalyptiq 4.06.2009, 14:24:10

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 http://pl.php.net/manual/en/ref.hash.php. Znalazłem tam ciekawą funkcję: http://pl.php.net/manual/en/function.hash-hmac.php. 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 http://pl.wikipedia.org/wiki/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 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?

Napisany przez: sowiq 4.06.2009, 14:38:53

Cytat(Apocalyptiq @ 4.06.2009, 15:24:10 ) *
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? 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)

Napisany przez: Apocalyptiq 4.06.2009, 14:49:15

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

Napisany przez: sowiq 4.06.2009, 14:59:12

Cytat(Apocalyptiq @ 4.06.2009, 15:49:15 ) *
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.
Cytat(Apocalyptiq @ 4.06.2009, 15:49:15 ) *
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ę 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ę.

Napisany przez: Apocalyptiq 4.06.2009, 15:30:31

Cytat(sowiq @ 4.06.2009, 15:59:12 ) *
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 :-)

Napisany przez: sowiq 4.06.2009, 15:44:24

Cytat(Apocalyptiq @ 4.06.2009, 16:30:31 ) *
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źć smile.gif

Napisany przez: Apocalyptiq 5.06.2009, 10:30:15

Cytat(sowiq @ 4.06.2009, 16:44:24 ) *
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źć 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.

Napisany przez: sowiq 5.06.2009, 11:16:03

Cytat(Apocalyptiq @ 5.06.2009, 11:30:15 ) *
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 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 smile.gif

Cytat(Apocalyptiq @ 5.06.2009, 11:30:15 ) *
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 smile.gif

Napisany przez: Apocalyptiq 5.06.2009, 13:32:13

Cytat(sowiq @ 5.06.2009, 12:16:03 ) *
Jeśli pracujesz dla Amerykańskiej armii i ochraniasz hasłem 'red button', to tak 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 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 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 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ł :-)

Napisany przez: viking 27.06.2009, 15:12:49

Już od kilku lat istnieje taki malutki projekcik http://www.openwall.com/phpass/ i chyba staje się coraz popularniejszy bo więcej darmowych skryptów zaczyna z niego korzystać (drupal, WP, ajkieś fora). Osobiście już dawno porzuciłem własne pomysły na rzecz tego. Najsilniejsza metoda to blowfish a ta z kolei według różnych testów jest też bardzo szybka. A i tak na nic nasze starania jeśli user trzyma hasło przypięte do monitora.

Napisany przez: Kocurro 10.07.2009, 06:26:05

Ja zawsze używam następującej metody i jak do tej pory nikomu się nie udało włamać.

W bazie trzymam następujące informacje o haśle:

MD5 z hasła
SHA1 z hasła
długość hasła

i oczywiście mam jeszcze użytą sól do zabiegów MD5 i SHA1, która jest generowana na podstawie informacji: id użytkownika, login użytkownika, data rejestracji (czyli tych danych, które są niezmienne).

Żeby umilić życie te trzy wartości mam zapisane odpowiednio w jednym ciągu. Na niektórych serwisach rezygnuję z użycia SHA1 ponieważ jak do tej pory MD5 z długością hasła dawało skuteczną ochronę.

Oprócz tego kody źródłowe, które są na serwerze są zakodowane więc nie jest łatwo rozpoznać jak dokładnie jest tworzone hasło. Sama zawartość bazy danych niestety niewiele pomoże. Aha - wspominałem już o tym, że wartości wpisywane do bazy o użytkowniku takie jak dane osobowe są zaszyfrowane a klucz szyfrujący/odszyfrujący znajduje się w zakodowanym kodzie źródłowym.

Wiem, że moja metody jest mniej skuteczna niż wielokrotne MD5 haseł ... ale muszę jakoś sobie radzić winksmiley.jpg

Pozdrawiam,
Łukasz

Napisany przez: yevaud 31.07.2011, 19:16:35

Często w tym wątku pojawia się problem szybkości algorytmu hashowania. Martwicie się, że algorytm będzie wolny, cieszycie się gdy md5 jest superszybkie. Wydaje mi się, że to podstawowy błąd na poziomie założen. Funkcje hashujące których używamy - i nie ważne czy będzie to md5, czy coś z rodziny sha2, albo nawet cos bardziej ekscentrycznego jak haval - nie zostały zaprojektowane do szyfrowania kilku/kilkunasto znakowych haseł, a do hashowania dużych bloków danych, lub do hashowania duzych ilości skrótów w bardzo krótkim czasie(np. podczas sortowania, lub w implementacji protokołu sieciowego). One naprawde SĄ szybkie:)

W przypadku haseł w serwisie webowym, operacja hashowania wykonywana jest tylko raz na każde logowanie, więc nie musi być bardzo szybka. Różnice zajętości ramu podczas obliczeń na poziomie kilu kb także nie są tutaj problemem. Dodatkowo np. obliczanie hasha nie powinno dać się zrównoleglić. Można pewnie wymienić jeszcze kilka założeń które będą prawdziwe dla haseł serwisu webowego, a niekoniecznie prawdziwe przy innych zastosowaniach.

Popatrzmy w jaki sposób można zaatakować hash w serwisie webowym:

a) brute-force. Najbardziej rozpowszechniona i najłatwiejsza metoda ataku.
Problemem jest bardzo duża szybkość komputerów. Atakujący może wygenerować olbrzymie ilości hashów w krótkim czasie. Dodatkowo niezabezpieczony formularz logowania może pozwalać na wielokrotne logowania w krótkim czasie. Za kilkaset $/h można wynając superkomputer obliczający 500,000,000,000 hashy na sekundę!

cool.gif slownik/brute-force
Problemem jest mała inwencja użytkowników przy wymyślaniu haseł

c) rainbow
Problemem jest generalnie brak "soli" smile.gif Atakujący ma wygenerowany słownik hashy

d) analiza różnicowa i inne metody matematyczne
W typowym serwisie webowym nie jest to problem, jednak warto pamiętać, że md5(md5($val)) będzie miało prawdopodobnie gorsze właściwości, niż pojedyńcze użycie funkcji hashującej, dlatego należy raczej unikać takiego rozwiązania. Problem wielokrotnego hashowania typu md5(md5(md5(...) leży prymitywnym sposobie podawania danych do funkcji -> tylko za pierwszym razem używamy całości dostępnych danych, za każdym następnym razem do funkcji hashującej wchodzą zawsze dokladnie 32 znaki, a większość "losowości" która tkwiła w oryginalnym haśle, jest (prawdopdobnie) powoli tracona przez funkcje mieszającą. Piszę prawdopodobnie bo nie udało się udowodnić do tej pory ani że jest tracona ani że nie jest, można jednak dość bezpiecznie założyć, że stałe 32 znaki poddawane cały czas temu samemu algorytmowi, maja raczej gorsze właściwości niż losowy ciąg znaków smile.gif

e) atak DOS
W przypadku serwisu webowego, atak na kolizję przy logowaniu nie ma za bardzo sensu, ale jeśli operacja hashowania jest kosztowna, można doprowadzić do wyczerpania zasobów serwera np. poprzez wielokrotne logownie.


Teraz remedium na nasze problemy:
e) ograniczenie ilości logowań, albo szybka funkcja hashująca
d) używanie całości danych wejściowych przy każdej iteracji algorytmu hashującego, używanie matematycznie poprawnych funkcji hashujących
c) sól.
cool.gif Słownik i odrzucanie idiotycznych haseł użytkowników. Narzucenie odpowiedniego poziomu skomplikowania na hasła.
a) Wolny algorytm hashowania! przez wolny, rozumiem np. ~10ms

No włąsnie, jak widać na końcu szybki algorytm hashujący, jest tak naprawde WADĄ w przypadku typowego serwisu webowego.

Po tym przydlugim wstępie, przejdę do sedna:
http://en.wikipedia.org/wiki/Bcrypt - nie mylić z http://bcrypt.sourceforge.net/
jest to algorytm który spełnia założenia które sobie postawiliśmy. Jest matematycznie poprawny, oparty na sboxach z blowfisha, a do tego można sterować jego złożonością tak żęby osiągnąć wymaganą szybkość(a raczej wolność). Niewielka modyfikacja w szybkości funkcji hashującej i atakujący który próbuje bruteforce potrzebuje nagle lat zamiast minut na złamanie haseł, a dla naszego serwisu różnica rzędu paru ms przy logowaniu nie jest zauważalna.

http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php

Podsumowując:
1. wolna, poprawna matematycznie funkcja hashująca typu bcrypt
2. słownik
3. ograniczenie ilości logowań
4. sól

Napisany przez: sobol6803 11.02.2012, 23:20:37

Witam. Wiem, że tu bardziej chodzi o hash haseł, ale ja mam pytanie o przenoszenie hash'a między serwerami. Np. jeśli w hashu chcemy przenieść 3 zmienne:

Kod
$id = 1;
$imie = 'andrzej';
$nazw = 'kowalski';


I chcę to przenieść na inny serwer, aby wykorzystać w formularzu w postaci tajnej:

Kod
$hash = md5($id.$imie.$nazw);


Dodaje do url'a i przechwytuję na inym serwerze w postaci:

example.com/form.php?hash=9812asd65017578gs23487 (liczby przypadkowe z klawiatury, jednak to jest ten wygenerowany hash).

Teraz chciałbym wpisać te 3 zmienne zakodowane w hashu do formularza. Jak to zrobić?

Z góry dzięki za pomoc smile.gif

Pozdrawiam.

PS. Sorry za odkopanie, ale nie chciałem specjalnie nowego tematu zakładać.

Napisany przez: Leihto 12.02.2012, 03:24:44

Jeśli chcesz mieć zdekodowane te dane to tak się nie da (a raczej Ty tego nie zrobisz).
jeśli ma to być hash wpisany w input to proszę:

  1. <!-- Link : example.com/form.php?hash=9812asd65017578gs23487 -->
  2. <form action="" method="POST">
  3. <input type="text" value="<?php $_GET['hash']; ?>">
  4. </form>


Podstawy podstawy podstawy!

Napisany przez: Amedos 20.08.2012, 05:34:45

A co myślicie by zrobić własne hashowanie ?
Funkcja str_replace

Napisany przez: erix 20.08.2012, 16:20:33

A czy przeczytałeś w ogóle ten temat...?

Napisany przez: mrWodoo 23.08.2012, 12:02:45

Najlepiej używać bcrypt, bo możemy dostosować 'trudność obliczeń' tzw. rundy, 12 rund tak zwolni prędkość ataku brute-force... że sobie to odpuszczą chyba, że to hasło do biur CIA / FBI smile.gif

http://www.codinghorror.com/blog/2012/04/speed-hashing.html


Bcrypt: php manual -> crypt

Napisany przez: amii 21.10.2012, 11:38:46

W manulau nie zalecają stosowania md5, sha1, sha256 do heszowania ze względu na zbyt dużą szybkość i możliwy atak brute force. Mam dwa pytania:
1. Czy md5, sha1 i sha256 itp. mogą wygenerwać dwa lub więcej takich samych kluczy dla różnych danych wejściowych ? Przypuszczam, że tak bo inaczej taki algorytm byłby doskonałym archiwizerem. W dokumntacji algorytmu md5 -> http://www.faqs.org/rfcs/rfc1321.html znalałem jednak coś takiego:

Cytat
It is conjectured that it is computationally infeasible to produce
two messages having the same message digest, or to produce any
message having a given prespecified target message digest.

Więc jak to jest ?
2. Wbudowane opóźnienie można osiągnąć za pomocą funckji http://pl1.php.net/manual/en/function.crypt.php gdzie określamy algorytm, sól i ilość iteracji (to jest wbudowane opóźnienie). Tyle, że funkcja crypt nie obsługiwana przez silnik bazy danych. Jeśli np. w Zend autoryzacja odbywa się przy pomocy Zend_Auth_Adapter_DbTable w ten sposób. To klasa wykorzystuje wbudowaną funcję silnika bazy danych czyli SHA1 i CONCAT
Jak uwierzytelnić za pomocą crypt ?
  1. $authAdapter = new Zend_Auth_Adapter_DbTable(
  2. Zend_Db_Table::getDefaultAdapter(),
  3. "users",
  4. "email",
  5. "md5",
  6. "SHA1(CONCAT('" . Zend_Registry::get('salt') . "', ?, salt))");

Napisany przez: erix 22.10.2012, 13:17:57

Cytat
Czy md5, sha1 i sha256 itp. mogą wygenerwać dwa lub więcej takich samych kluczy dla różnych danych wejściowych ?

Tak, gdyż wynika to z dziedziny, w której są tworzone hashe. Jest ona znacznie bardziej ograniczona niż treść, którą można hashować.

Cytat
2. Wbudowane opóźnienie można osiągnąć za pomocą funckji crypt gdzie określamy algorytm, sól i ilość iteracji (to jest wbudowane opóźnienie). Tyle, że funkcja crypt nie obsługiwana przez silnik bazy danych. Jeśli np. w Zend autoryzacja odbywa się przy pomocy Zend_Auth_Adapter_DbTable w ten sposób. To klasa wykorzystuje wbudowaną funcję silnika bazy danych czyli SHA1 i CONCAT
Jak uwierzytelnić za pomocą crypt ?

Masz tu błędne założenie projektowe - PO CO obarczać bazę hashowaniem?

Napisany przez: amii 25.10.2012, 15:58:05

To akurat nie moje założenie tak jest zaimplementowana metoda w zend framework, jakoś jednak przeżyje z sha1 + podwójna sól. No chyba, że ktoś na zend posługuje się crypt i byłby chętny opisać jak się za to zabrać

Napisany przez: Neymar11 21.02.2015, 03:00:41

Zawsze offtopowałem ^^.
A do tematu:

Można zrobić coś takiego, myślę że to coś da

  1. <?
  2. $rand = http://www.php.net/rand(1,11);
  3. $dodatek = http://www.php.net/md5($rand);
  4. $haslo = 'megatajne123';
  5. $hashcalk = http://www.php.net/md5($rand, $haslo);
  6. http://www.php.net/echo $hashcalk;
  7. ?>

A output raw bardzo dziwny haha.gif:
y Z��o��~���
Nie wiem co to znaczyć ma, no ale myślę że hasło zahaszowane dobrze haha.gif Raczej te kilka bajtów ktoś by rozszyfrowywał z 10 lat hahahaha biggrin.gif

Napisany przez: Forti 21.02.2015, 08:24:20

Cytat(Neymar11 @ 21.02.2015, 03:00:41 ) *
Zawsze offtopowałem ^^.
A do tematu:

Można zrobić coś takiego, myślę że to coś da
  1. <?
  2. $rand = http://www.php.net/rand(1,11);
  3. $dodatek = http://www.php.net/md5($rand);
  4. $haslo = 'megatajne123';
  5. $hashcalk = http://www.php.net/md5($rand, $haslo);
  6. http://www.php.net/echo $hashcalk;
  7. ?>

A output raw bardzo dziwny haha.gif:
y Z��o��~���
Nie wiem co to znaczyć ma, no ale myślę że hasło zahaszowane dobrze haha.gif Raczej te kilka bajtów ktoś by rozszyfrowywał z 10 lat hahahaha biggrin.gif



to niczym się nie różni jak zwykłe md5($haslo, $sól). Masz bcrypt od takich zadań.

Napisany przez: Crozin 21.02.2015, 08:47:25

To na dobrą sprawę jest nic innego, jak

  1. http://www.php.net/md5(http://www.php.net/rand(1, 11), true);
To nawet skrót hasła nie jest i tylko przez idiotoodporność PHP-a błędami na lewo i prawo nie rzuca. Pod żadnym pozorem nie powinno się z czegoś takiego korzystać.

Napisany przez: Neymar11 2.05.2015, 19:28:12

A ogarnijcie to:

  1. <?
  2. function hash($string) {
  3.  
  4. $hashe = http://www.php.net/array(
  5. "sha512","ripemd128","ripemd256","ripemd320","whirlpool",
  6. "tiger128,3","tiger160,3","tiger192,3","tiger128,4","tiger160,4",
  7. "tiger192,4","snefru","gost","adler32","crc32","crc32b");
  8. foreach($hashe as $hash) {
  9. hash($hash, $string);
  10. }
  11. return $string;
  12. }
  13. ?>


ma to sens? tongue.gif
wklejcie do notatnika, zincludujcie albo w tym samym pliku poza funkcja echo hash('string');
mysle ze cos da ^^ ciekawe, jak bardzo przedluza czas wykonania niz samo md5 tongue.gif

Napisany przez: pyro 2.05.2015, 20:03:10

Cytat(Neymar11 @ 2.05.2015, 19:28:12 ) *
A ogarnijcie to:

  1. <?
  2. function hash($string) {
  3.  
  4. $hashe = http://www.php.net/array(
  5. "sha512","ripemd128","ripemd256","ripemd320","whirlpool",
  6. "tiger128,3","tiger160,3","tiger192,3","tiger128,4","tiger160,4",
  7. "tiger192,4","snefru","gost","adler32","crc32","crc32b");
  8. foreach($hashe as $hash) {
  9. hash($hash, $string);
  10. }
  11. return $string;
  12. }
  13. ?>


ma to sens? tongue.gif
wklejcie do notatnika, zincludujcie albo w tym samym pliku poza funkcja echo hash('string');
mysle ze cos da ^^ ciekawe, jak bardzo przedluza czas wykonania niz samo md5 tongue.gif


Nie ma:

Po 1: Bo infinite recursion

Po 2: Sam "tok myślenia" takiego kodu to pomysł delikatnie mówiąc wysoce nierozsądny

Napisany przez: darek334 21.03.2017, 12:19:02

Cytat(nospor @ 23.03.2006, 08:34:33 ) *
Przyznam szczerze, iż nie wiem jak robi się w praktyce ataki b-f. Nigdy nie robilem wink.gif 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.

Bardzo dobre spostrzeżenie wówczas po-któreś tam hashowanie nie ma znaczenia, tylko obciąża kod po stronie serwera. Jeśli tak mogę się wtrącić w dyskusję a do tego postu doszedłem tylko.
Natomiast hashowanie haseł nie jest metoda kompresji, ktoś kto tak myśli bardzo sie myli, to że powstają 32 znaki o tym nie świadczy, to błędny wniosek. Raz że takie hashowanie powinno być jednostronne a dwa że jest stratne, czyli za długie treści są obcinane, po to właśnie, aby nie można było odszyfrować tego hasła, nie zawsze tak jest, ale tak powinno być. Algorytm matematyczny nam to gwarantuje, unikalność hasha i tylko wyniki są porównywane jeśli tak to jestes zalogowany itp - to aluzja do wcześniejszego posta.
Natomiast co do łamiania algorytmów (nie brute force) to nie nie odbywa sie to tak jak sie wielu wydaje. Przykładem może być base64_encode, proszę sobie kilkukrotnie kodować jakąs treść i zobaczyć wynik. Jeśli dany algorytm jest złamany to nie będzie miało znaczenia ile razy był użyty bo będzie to rozpoznawalne, przedłuży pracę ale da sie zrobić i czas nie będzie zbytnio długi, bo złamanie nie jest tak czasochłonne jak brute force.

Napisany przez: nospor 21.03.2017, 12:24:13

Skoro przytoczyles moja wypowiedz sprzed ponad 10 lat to ja moze tylko uaktualnei to troche:
wtedy byla mowa o zwyklym md5, sha1, i dodaniu jakiejs tam soli.
Teraz, gdy w metodach hashowania mozna okreslic, ze hashowanie ma zajac np. 1sekunde, to juz metoda hashowania na serwerze ma znaczenie, gdyz moze bardzo znacznie wydluzyc czas ataku BF i najzwyklej w swiecie taki atak sie nie powiedzie spowodow czasowych smile.gif

Napisany przez: Przemek19 4.06.2017, 20:12:13

Nie lepiej zrobić coś takiego?

  1.  
  2. $haslo = "Konstantynopolitańczykówianeczka";
  3. $hash = hash(http://www.php.net/md5,$haslo);
  4.  
  5. for($i=1;$i<=10000;$i++)
  6. {
  7.  
  8. $hash = hash(sha1,$hash);
  9.  
  10. }
  11.  
  12. http://www.php.net/echo $hash;
  13.  

Napisany przez: nospor 4.06.2017, 21:06:09

@Przemek19 Polecam przeczytac ten temat od poczatku. Masz tam wyjasnione czemu twoja metoda jest totalnie do bani i totalnie niebezpieczna

Napisany przez: Przemek19 4.06.2017, 21:15:37

Ok, miałem 2 minuty, więc nie doczytałem tongue.gif

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)