Według tego jacyś chińczycy złamali SHA-1 - i czym my teraz będziemy hashować?

To moze SHA-256 albo SHA-512... ? :/

Edit: ok... z sha-* mozna sie pozegnac tez nie sa bezpieczne... zostaje wiec RIPEMD-160

Według Wikipedii RIPEMD jest kolizyjny, więc... Może napiszemy własny? 8>
A tak na serio to już samo hashowanie nigdzie nie wystarczy... trzeba wszystko HMACować...

RIPMED (oraz wersje 128, 256 i 320) tak ale juz nie wersja 160... wiec moze nie bedzie tak zle...
Swoja droga wglada na to, ze na dobra sprawe hashowanie jest tylko w zalozeniach nie do zlamania.

Swoja droga przypomnialo mi sie jak kiedys Kubatron tlumaczyl jak rozkodowac md5 :-)
Pozatym nie uwieze dopuki nie przetestuje ;-)

[PHP] pobierz, plaintext 
<?
$jakis_hash=mash(md5(sha1($cos_do_zhashowania)));
?>
[PHP] pobierz, plaintext 

Jak @Seth pisze -kazdy sposob hashowania jest tylko teoretycznie niezłamywalny

czy wy się wściekliście? ... to złamcie hash z płyty 700 mb i podajcie mi dane jakie na niej były ...

witam ...

tu chodzi o kolizje ... majac dany hash mozna wygenerowac dane ktore maja taki sam hash ... to nie oznacza ze da sie odgadnac dane poniewaz to jest nie mozliwe i nie bedzie nigdy [hash to jak kompresja stratna] ... wydaje mi sie ze pomysl z 2 roznymi hashami jest dobry ... mozna jeszcze ew przechowywac 2 hashe ... jeden z sha1 drugi z md5 ... odgadniety string z sha-1 [inny niz orginal] nie bedzie odpowiadal zhashowanemu w md5 ... robimy test na true i po sprawie ...

pozdrawiam

orson: idac twoim tokiem rozumowania ... majac hash mozna wygenerowac dane o takim hashu wychodzi na to ze mozna odzyskac zahashowane dane ... ale dla ograniczonej dlugosci ciagu danych ...

tylko jak to sie ma do tego ze hash ciagu pustego istnieje rowniez.

dla mnie to jest totalnie irracjonalne.

orson: dokladnie o to mi chodzilo mowiac lamanie hasha, chociaz zle sie wyrazilem.

PMadej: nie mozna odzyskac zahashowanych danych. Mozna jedynie uzyskac ten sam hash.
Czyli np. majac hash hasla mozemy podac inny ciag znakow ale takich, ktore utworza ten sam hash i pzowoli nam to na zalgowanie sie.

A to?
http://www.vmpcfunction.com/function.htm

dzięki za wyjaśnienie ... o to własnie mi chodziło

witam ...

@Imperior: czytalem o tej funkcji zaraz jak sie pojawila bo bylo o niej slychac [wymyslil ja polak] poniewaz jest bardzo trudna do "zlamania" [przez zlamanie mam na mysli kolizje - 2 rozne stringi daja ten sam hash] a proces hashowania jest bardzo latwy [nie wymaga duzej wydajnosci - przenosne uzadzenia, telefony itp] ale mam jedna zasadnicza wade ... nie ma jej natywnie w php niby mozna napisac funkcjie ktora bedzie hashowac ale moga byc problemy ... i nie bardzo mi sie chce

@Seth i @PMadej: ludzie bardzo czesto to myla ... nie da sie odzyskac zhashowanych danych ... kompresja stratna nazywa sie tak nie bez powodu ...

rozwiazanie z przechowywaniem wynikow z 2 roznych hashow na tym samym stringu wydaje mi sie najlepsze ...

pozdrawiam

@orson: wiem, nie musisz mnie o tym uswiadamiac poprostu to bylo przejezyczenie/skrot myslowy/nie dopatrzenie (niepotrzebne skreslic )

Ale swoja droga zastanawiam sie po co przechowywac dwa hashe ?
Przeciez na dobra sprawe problem ten w przypadku np. logowania nie ma wiekszego znaczenia. Mozna sie martwic o to czy ktos kto ma dostep do bazy danych nie bedzie chcial uzyskac tekstu z identycznym hashem po to aby uzyc go do "wlamania sie" na inne nasze konto - o ile uzywamy "tam" tego samego hasla.
W przypadku serisow/uslug gdzie wysylany jest hash mozna go przejac i wtedy rzeczywiscie problem jest powazny, ale tak jak wyzej napisalem, nie w przypadku np. logowania sie do naszego konta np. w panelu strony.

witam ...

wlasnie ... dlatego nadal bede uzywal przez jeszcze dlugi czas sha-1 do przechowywania hasel ... podalem rozwiazanie gdy ktos potrzebuje czegos bezieczniejszego ... kierowalem sie tonem wypowiedzi autora watku [panika ]

pozdrawiam

@orson - nie wiem czy zauważyłeś, ale na końcu mojego zdania jest emotikonka - gdyby jej nie było to fakt, można by powiedzieć że panikuje, ale ponieważ jest, to można chyba wywnioskować że nie biorę tego w 100% na poważnie?

I oczywiście, sam fakt możliwości kolizji tak na prawdę niczego nie łamię (o wiele 'ciekawsze' są różne inne rzeczy) - ale mimo wszystko jest to fakt godny odnotowania, i zdecydowanie godny zapamiętania...

No i co z tego ze zlamane, skoro predzej wygra sie w totka niż dopasuje hashe - bo najpierw trzeba je zdobyć (nikt raczje nie podaje hasha swojego hasła na stronce) i dopiero potem złamać.
Wiec sądze że można nadal spać spokojnie

@Spenalzo: zdobycie hasha jest naprawdę banalnie proste. Hasha przecież sami ci podają.

Cała dyskusja o hashowaniu haseł jest niewarta uwagi, bo to NIE jest istotnie zastosowanie hashy. Taki sobie bajer. Hashy używa się do:
- weryfikowania poprawności dokumentów cyfrowych
- weryfikowania poprawności softwaru
- weryfikowania poprawności linków edonkey
- weryfikowania...

Jeżeli masz podpisany cyfrowo dokument, w którym jest napisane, że płacisz komuś $500, a ktoś zrobi z tego również podpisany przez ciebie dokument opiewający na $5000, to dalej będziesz spać spokojnie? Fakt, że taka ingerencja jest prawdopodobnie niemożliwa, bo trzeba znaleźć taką kolizję, która generuje pożądany tekst. Ale np. jak masz dokument Worda, to możesz dodać metadane itd i jest łatwiej.

Co do linków edonkey, to jest coś dla gości od piractwa. Bardzo ciekawe zastosowanie... możesz wpuścić w sieć fałszywkę, która składa się z dowolnego ciągu bajtów i udaje np. film. Nikt nie będzie w stanie odróżnić tego od oryginału, dopóki nie ściągnie i nie spróbuje odtworzyć. Gdyby udało się znaleźć sposób na generowanie jakichkolwiek kolizji w rozsądnym czasie, to można rozłożyć działające obecnie sieci P2P.

Czyli trzeba najpierw wiedzieć, do czego w ogóle używa się hashy. I naprawdę, nie chodzi tutaj o md5($password).

BTW, bez paniki. 2**69 to i tak kupa czasu. Ponadto cała idea nie jest do końca opracowana; nawet nie opublikowali oficjalnie raportu. Problem polega na tym, że po raz pierwszy ktoś ogłasza, że ma sposób na złamanie SHA-1 inny niż brute force (czyli 2**80). Czyli SHA-1 ma słabe miejsca. Czyli za jakiś czas ktoś może zrobi z tego 2**49. Najtrudniejszy jest pierwszy krok.

edit: @Imperior: A VMPC to jest w ogóle hash? Na samym początku autor się chwali, że odwrócenie funkcji wymaga 2**260 operacji. Fajnie, tylko że hashy się z definicji nie odwraca... OK, autor opisuje jeszcze VMPC-MAC, o długości 20 bajtów. 20 bajtów = 160 bitów, czyli znalezienie kolizji wymaga 2**80 operacji (brute force), a nie 2**144. Coś mi tu wygląda na pieprzenie w bambus...

@Hawk: Jestem naprawdę wdzieczny za twojego posta, bo dopiero to mi rozjaśniło troche w głowie.

Jest możliwa... polecam najnowszy numer hackin9. Opisane na przykładach... skrypty dolaczone na CD. Wszystko opiera sie na badaniach pewnych chinskich naukowcow.

@Vengeance:

1. Pewnie tej samej grupy naukowców, którzy złamali SHA-1...
2. Czy hackin9 nie jest płatny? Więc niestety nie mogę sprawdzić.
3. Skrypty na CD? Come on, coś tu jest nie tak. Ja ci wyślę kawałek tekstu (np. zamówienie) i hash SHA-1, a ty mi znajdziesz za pomocą tych skryptów inny kawałek, który dalej ma sens, i którego hash jest taki sam?

1. nie wiem, możliwe
2. zawsze można zobaczyć w empiku czy coś Nie kazałem kupować.
3. Chodzi mi o skrypty demonstracyjne. Zresztą są to chyba skrypty/programy napisane przez tych naukowców. Watpie (tak samo jak ty) czy działają tak hop siup na każde dane. W każdym badz razie w artykule jest przedstawiony proces robienia dwoch omow (jedna opiewa na sume o jedno zero większą) ktore posiadaja ten sam hash md5. Do tego sluza ow skrypty na CD


-----edit-----
Masz "fart". Artykuł dostępny jest za free tu:
http://www.hakin9.org/pl/attachments/md5_pl.pdf

Thnx za artykuł. Ciekawy i przystępnie napisany.

Chociaż należy pamiętać, że artykuł opisuje atak na MD5. A MD5 niestety ma dziury. Z SHA-1 jest inaczej: publikacja, która zapoczątkowała ten wątek, jest pierwszym na świecie przykładem, że SHA-1 można próbować złamać inaczej niż metodą brute force. Więc jeszcze sporo czasu minie, zanim ktoś będzie w stanie to wykorzystać.

A druga uwaga dotyczy błędu w artykule:

Otóż wcale nie. Minimalizacja tego prawdopowobieństwa możliwa jest tylko poprzez wydłużanie hasha, co pozbawia całą operację sensu - równie dobrze można przyjąć hash(x) = x. Hash powinien być generowany w ten sposób, aby wygenerowanie drugiej wiadomości mającej taki sam hash było jak najtrudniejsze. Atak brute force zajmuje 2**(hash length/2) prób, niezależnie od użytego algorytmu. I dobry hash to taki, dla którego nie istnieją metody otrzymywania kolizji mające mniejszą złożoność obliczeniową.

Witam.
Trochę nie rozumię dyskusji z powodu mojego rozumowania o Hashowaniu od momentu jak zobaczyłem md5.

Więc jeśli md5 zwraca ciag 32 znakoway ... liczby + cyfry ... to ilość kombinacji jest ograniczona i zawsze istnieje możliwośc istnienia nieskończonej ilości ciągów które po md5 dadzą ten sam rezultat.

Ale własnie to mi się wydawało plusem. Gdyz po kazdy Hash miałby wiele wzorów i nie dało by zgadnąć która wersja jest właściwa.

Przecież hashując 700MB danych zawsze jest możliwośc ze wyjdzie taki sam HASH jak po shashowaniu literki "a".

Czy z tymi kolizjami właśnie o to chodzi ? Że znaleźli jakieś 2 ciągi które zwracają identycznego HASH'a

Tak, dokladnie. Znaleziono conajmniej dwa ciagi, ktore daja taki sam hash.
Co znaczy, ze md5 nie jest roznowartosciowe. Ale to bylo wiadomo od zawsze, gdyz tak jak wspomniales na 32 bitach da sie zapisac ograniczona ilosc kombinacji.

Jednakze problem nie lezy w tym co napisales, zeby odgadnac ktora z "od"hashowanych wartosci po zhashowaniu daje nam naszego hasha. Zagrozenie przedstaie na przykladzie:
mamy forum phpbb tam hasla sa zhashowane md5 i mamy takiego admina, ktorego haslo zhashowane w bazie ma jakas postac. Problemem jest to, zeby istnial tylko jeden ciag (wlasnie ten, ktory wprowadzil admin jako swoje haslo) ktory po zhashowaniu daje ten zapisany w bazie, ale jak juz wykazano takich ciagow istnieje wiele.
Jednakze ja bym sie tym nie przejmowal, gdyz jak narazie nie ma funkcji odhashowujacej kody, jest co najwyzej tablica "wielu" hash'y.

ps. to w koncu rozmawiamy o md5 czy sha-1

Tak czy siak predzej czy pozniej ktos zlamie to co wydawalo sie nie do zlamania. Na nasze szczescie powstaja nowe metody kodowania, ktore niedlugo bedzie mozna wykorzystac. Hmm to mi wyglada na zabawe w kotka i myszke. Coraz nowsze technologie, coraz szybsze komputery i coraz szybsze lamanie metod kryptograficznych. Wymysla nowa metode do kdowania i znowu ja zmalna...
Wyglada na to ze trzeba bedzie byc na topie

A moze sie myle...

[ a tak po za tym... witam po strasznie dlugiej nieobecnosci na forum ]

Prawada jest taka, ze obecne metody szyforwania danych opieraja sie na tym, ze na ich zlamanie potrzebna byla by duza moc obliczeniowa. A wiec im postep komputerowy jest szybszy tym czesciej odkrywane sa "luki".

Dobrze zapowiada sie kryptografia kwantowa ale na dostep do niej dla przeietnego uzytkownika pewnie jeszcze trzeba bedzie dlugo poczekac.

Problem jest taki ze aby cos zaszyfrowac a później odszyfrować konieczny jest jakis klucz albo algorytm który dziala jakby klucz i to da się zawsze złamać. A trzeba znaleźc zupełne świerze podejście do tego, takie które nie polega na kluczach, czy algorytmach, no ja sam nie wiem jak to mialo by wygladać po prostu inaczej

By dorzucić coś od siebie do tematu szyfrowania danych zacytuję fragment książki jaką ostatnio miałem przyjemność zakupić i przeczytać...

Jeżeli ktokolwiek z Was interesuje się kryptografią, to gorąco mu polecam tą pozycję.
Nie traktujcie tego jako reklamę - jest ona zbędna... Brown i tak jest już bardzo popularny.
W książce znajdziecie odpowiedź czy istnieje szyfr (hash) zupełnie bezpieczny i jak wygląda.

Jak dla mnie informacje o złamaniu jakiegoś szyfru są mało warte - czy tego chcemy, czy nie, Kevin Mitnick w swojej książce już pokazał światu jak łatwo można złamać niemal nieskończenie długie klucze kryptograficzne, hasła i jakiekolwiek inne sposoby zabezpieczania danych...
Szkoda tylko, że pomimo tak wielu sygnałów ze świata, że ludzie to ciemna masa w dziedzinie bezpieczeństwa nadal się nic nie robi, by tą sytuację zmienić...
Nie wyobrażacie sobie nawet jak łatwo dostać się na większość kont pocztowych na takich serwerach jak tlen, onet, wp...
Przypomnienie hasła jest wyjątkowo kiepskim rozwiązaniem przy obecnej wiedzy większości ludzi posiadających konta w w/w portalach...

Wnioskiem z tej rozmowy może być stwierdzenie, że łamanie szyfrów przy pomocy metod brutal force (i nie ma znaczenia ile jest możliwości, czy jest to jakoś ułatwione przez błędy w algorytmach...) jest nie opłacalne - znacznie skuteczniejsza jest socjotechnika - odrazu dostajemy wynik.
Ludzki mózg jest znacznie lepszy w łamaniu szyfrów niż najlepsze komputery.

nie ma sie co dziwic, w koncu wszystko każde zabezpieczenie jest do złamania, wiec nic tak na prawde nie chroni na 100% danych. na samym poczatku bregovic napisał:


Po co ktos by miał ktos wlamywac sie na prywatne strony, skoro nic mu z tego nie przyjdzie?

@cartman, to chyba oczywiste ze nie chodzi o dane, ktorych wykradniecie, nic nie przynosi zlodziejowi. zreszta takie informacje oczywiscie nie sa szyfrowane (chyba tylko przez nadgorliwcow). poza tym, nikt tu nie pisal ze chodzi o prywatne strony.

To ja mam do Was takie pytnanie (o kryptografii nie wiem prawie nic wiec jesli to bedzie dziecinne, to z gory przepraszam )

mamy taki kod:

[PHP] pobierz, plaintext 
<?php
$zakodowane_haslo = sha1(sha1($niezakodowane_haslo));
?>
[PHP] pobierz, plaintext 

a wiec:
$niezakodowane_haslo --sha1--> xxxx --sha1--> yyyy

gdzie yyyy to zawartosc zmiennej $zakodowane_haslo

Teraz ktos wyciaga hash yyyy i znajduje ciag zzzz ktory po shashowaniu da yyyy, czyli

zzzz --sha1--> yyyy

przy czym zzzz moze byc tym samym ciagiem co xxxx ale nie musi (o ile dobrze Was zrozumialem).

Moje pytanie jest nastepujace:
Czy po wykonaniu ponizszego kodu otrzymam yyyy?

zzzz --sha1--sha1-->

czyli inaczej

$czy_tu_bedzie_yyyy = sha1(sha1(zzzz));

Jesli nie to wykradzenie z bazy hasha nie wiele da, bo trzebaby znalezc zrodlo drugiego hasha a potem zrodlo pierwszego, przy zalozeniu ze ob byly z sha1.Jesli nie bedzie wiadomo jakich funkcji uzylismy i w jakiej kolejnosci to chyba w ogole pies pogrzebany....

Prosze o komentarze i pozdrawiam

wiec podwojne hashowanie jest jakims wyjsciem bo masz racje

nie da nam yyyy. a raczej jest bardzo male prawdopodobienstwo ze otrzymamy to samo. niby to jest jakies rozwiazanie ale i tak nie jest dalej w 100% pewne. ta dyskusje mozna ciagnac bez konca

No dobra ale jak zamiast $niezakodowane_haslo damy jakieś inne które da te same hashe to też "wejdziemy".

Nie wiem czy dobrze mysle ale jesli nie znasz funkcji kodujacych, to jak na podstawie ostatniego hasha chcesz dostac sie na konto? Zostaje Ci co najwyzej mozolne sprawdzanie kilku kombinacji sha1 z sha1, sha1 z md5, md5 z sha1...a moze password z sha1...itd

Na podstawie dlugosci ostatniego hasha jestes w stanie odkryc jakimi funkcjami byl kodowany ale nie wiesz jaka byla pierwsza funkcja,ktora do niego doprowadzila.
Poza tym istnieje kwestia czy ciag ktory jest obliczony na podstwie hasha jest tez np 32 bajtowa liczba...,bo jesli tak to juz w ogole nie jestes w stanie sprawdzic jaka byla pierwsza funkcja hashujaca.

<:) tak sobie mysle... (

problem ten jest filozoficzny zawsze mozesz przyjac zalozenie ze wlamuja Ci sie na serwer i kopiuje plik z haslami oraz plik w ktorym masz zapisana funkcje hashujaca i juz wie co i jak. tylko ze w takim wypadku po co mu haslo jaki i tak ma dostep do serwera
czyli mozemy prowadzic ta polemike jeszcze dlugo

racja

Tyle ze ja wlasnie pisze projekt ktorego temat zwiazany jest z bankowoscia...a wiec kwestie bezpieczenstwa sa dla mnie priorytetowe.

..w sielance ze md5 jest bezpieczny tkwilem do wczoraj, kiedy to implementujac go sobie w skrypcie natrafilem na artykuly o zlamaniu sha1 i md5.A teraz mam problem czego uzyc...

gdzies tam wyczytalem zeby jeszcze sprawdzac dlugosc hasla, co faktycznie jest znacznym utrudnieniem dla potencjalnego wlamywacza.

@folklor, prawda jest taka ze 100% zabezpieczenie czegokolwiek jest niemozliwe. mozna tylko zblizac sie do tej granicy ale nigdy nie mozna jej osiagnac. stosowanie md5, sha1 wciaz jest uwazane za bardzo bezpieczne, jednak trzeba sobie zdawac sprawe ze maja swoje slabosci. mozesz wprowadzic bardzo duzo zabezpieczen, jednak problem pojawia sie wtedy, gdy maja bardzo duzy wplyw na wydanosc.

i tu albo napisz cos swojego albo kombiunuj ozne kombinacje ze srodkow dostepnych ale moje zdanie jest takie ze dopoki nie wlamia sie na serwer to jestes bezpieczny. a co do haslo to mozesz stosowac np. jak ktos zle wpisze 3 razy to czasowo blokuje konto a jak jest jakas wazniejsza czynnosc to haslo czasowe na maila lub w miare mozliwosci na sms ale i tak jak polak chce to da rade i sie wlamie

Apropo kryprotgrafi i bezpieczeństwa przypominam sobie jeden z ważniejszych wniosków z jedego wykładów na ten temat.
Niestety - nie pamietam, jakiej metody kryptograficznej to dotyczyło (a nie chce mi się szukać notatek), w każdym razie wielokrotne zastosowanie tej samej metody szyfrującej na określonym ciągu wbrew pozorom nie podnosi w sposób geometryczny złożoności obliczeniowej wymaganej do złamania szyfru. Pokazuje to, że jeśli jakaś metoda szyfrująca ma swoje słabości (a praktycznie każda ma) to zawsze będzie możliwe dotarcie do nich.
I choć haszowanie działą nieco inaczej niż szyfrowanie, to jednak, jak sądzę, zasada jest ta sama.

@falkor: całe to zamieszanie z tymi samymi hashami itd... nie dotyczyło sytuacji sha1($hasło_użytkownika);

Nie masz się czego obawiać. Tu konfliktu raczej user sam nie wywoła.
Co innego, jeśli ktoś zdobedzie hash i metoda brute-force bedzie chcial poznac prawdziwe hasło. Wtedy dwukrotne hashowanie porządnie wydłuży mu czas tego (a wręcz uniemożliwi?)

@DeyV: Prawda. Wielokrotne stosowanie tego samego algorytmu nie jest rozwiązaniem. Chociaż np. 3DES miał już duży sens, bo zwykły DES po prostu się zestarzał. Do czasu kiedy departament obrony nie wybrał AESa . BTW, taki np. 3DES nie jest po prostu 3-krotnym powtórzeniem algorytmu DES. Druga transformacja jest przeprowadzana w drugą stronę, i oczywiście używany jest inny klucz. Wielokrotne hashowanie powinno dawać bardzo słabe rezultaty, bo od drugiej iteracji operujemy już na bardzo krótkim ciągu wejściowym i nie mamy możliwości zmiany klucza albo transformacji w drugą stronę.