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
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
Ja też myślalem że przepuścić przez md5 dwa razy będzie lepiej, ale ja to bym zrobil tak.
<?php $tajny_ciag = '23mjdkifjS1lpo321lpSAo5c90sawe3'; $zaszyfrowane = http://www.php.net/md5($tajny_ciag.http://www.php.net/md5($tajny_ciag.$_POST['pass'])); ?>
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
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 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.
[offtopic mode on]
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
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.
Kurka wodna, jak to potrafią czlowiekowi wodę z mózgu zrobić....
Jak tak czytam kolejne wypowiedzi, to zaczynam wierzyć w lekki sens tego kombinowania
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
Zgadza sie - na b-f nic sie nie poradzi ale podwojny hash dla takiego czegoś:
http://gdataonline.com/seekhash.php
to już bedzie problem.
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 , 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
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 ;]
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
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
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
md5 da się odhaszować.
http://md5.rednoize.com/
Więc lepiej używać sha1
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?
Ja tak robie
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
<?php $pass = http://www.php.net/md5( sha1($_POST['pass']) . $_POST['pass'] ); ?>
<?php $pass = sha1( http://www.php.net/md5($_POST['pass']) . $_POST['pass'] ); ?>
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...
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
"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? Także uważam, że 2xHash (czy jakie kolwiek inne sposoby na dodawanie smieci do hasla usera zanim je zahashujemy) ma sens.
widze że się nie rozumiemy
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).
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
Vengance on nawet nie musi tego wiedziec cala brudna robote odwala za niego twoje wlasne skrypty 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
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)
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ś
~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ł
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.
Odswierzam troche temat ale mysle ze moje pytanie najlepiej pasuje wlasnie do tego,
cos w ten desen ale przy 12 znakach nie znalazł hasha bardzo wybrakowane te tablice np nie łamie hasha zbudowanego w oryginale z ciagu cyfr
jednym słowem jeszcze daleko brakuje do łamacza hashów z prawdziwego zdarzenia...
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 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
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ć . 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ą.
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.
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 Hyba nie bo znając hasha: f:X-> {a}, aby poznać hasło jawne musimy poznać cały zbiór X (przynajmniej teoretycznie).
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ć.
@Michu
"Słabość MD5 polega na tym że wszyscy znają ten algorytm, dlatego teorytycznie da się go 'odhashować'."
Nie jestem kryptologiem, ale na kryptografii trochę się znam. Wszyscy ludzie, którzy są/mogą być autorytetami w tej dziedzinie, uważają, że nie można w kryptografii podchodzić do tematu przez tzw. security by obscurity. Przynajmniej publicznie żaden szanowany/szanujący się specjalista nie popiera takiej metody. Algorytmy powinny być udostępniane każdemu zainteresowanemu właśnie dlatego, żeby ludzie mogli znajdować ich słabości i je udoskonalać.
"Jeśli więc utrudnić procedurę hashowania, np. dodając nowe znaki, zamieniając kolejność znaków, mieszając hashe, odcinamy hakerowi możliwość złamania szyfru bo nie wie on jak go złamać."
MD5 można rozbić – czyli:
- mamy ciąg znaków A z którego robimy skrót X
- szukamy takiego ciągu B którego skrót też będzie wynosił X.
Przy hasłach takie działanie nie ma sensu – szansa na rozbicie MD5 jest wielokrotnie mniejsza niż na znalezienie hasła za pomocą metody bruteforce.
To co proponujesz – wprowadzenie dodatkowych mini zmian w wyniku działania MD5 nie ma większego sensu. MD5 jest wystarczająco mocne do większości zastosowań – żaden szanujący się włamywać nie będzie próbował go rozbijać – coś takiego wymaga olbrzymiej mocy przerobowej.
Może za 20 lat będziesz mógł rozbijać MD5 na jakiś większych maszynach – ale jeszcze pozostaje problem długości ciągu znaków – ciąg A może mieć 10 znaków, ale ciąg B może mieć kilkaset MB – ograniczenie długości znaków w polu wpisywania hasła może być dobrym pomysłem.
Na Twoim miejscu przestałbym się przejmować ezoterycznymi problemami MD5 i zająłbym się szukaniem błędów w innym miejscu
MD5 zostało złamane już kilka lat temu (w sierpniu 2004 dokładnie). Obecnie znane są metody, które pozwalają na znalezienie kolizji na domowym pececie w parę godzin. Dodam, że niedawno znaleziono także pewne luki w SHA-1, ale nawet po ich zastosowaniu potrzebny czas wykracza poza możliwości współczesnych komputerów.
Z drugiej strony, masz 100% racji, że siła obecnych systemów kryptograficznych tkwi w matematyce i jawności algorytmów. Eksperymentowanie na oślep i utajnianie algorytmu nie ma żadnego sensu, gdyż zdolny kryptoanalityk rozwali taki pomysł bardzo szybko. Szansa, że przez przypadek stworzymy coś naprawdę mocnego, jest nikła. Przeważnie sprawy tylko się pogorszą, a przykład widać w przesądzie, że H(H(k)) jest silniejsze niż H(k) .
Ech, wystarczy w Google wpisać "MD5 collisions" i masz tyle źródeł, że głowa boli .
http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf - praca poświęcona jednemu z algorytmów wyszukiwania kolizji
http://it.slashdot.org/article.pl?sid=05/11/15/2037232 - informacja o publikacji kodu źródłowego do wyszukiwania kolizji
http://eprint.iacr.org/2006/105 - praca nt znajdowania kolizji MD5 w minutę na domowym pececie.
Poza tym:
- udało się wygenerować dwa sensowne pliki Postscript z tym samym haszem.
- udało się wygenerować dwa różne certyfikaty X.509 z tym samym haszem.
Porównanie trzech metod przechowywania haseł jako hashe md5:
1. md5( HASLO )
<?php $login = http://www.php.net/mysql_real_escape_string( $_POST['login'] ); $haslo = $_POST['haslo']; $haslo = http://www.php.net/md5( $haslo ); $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() ); if( http://www.php.net/mysql_num_rows( $result ) ) { // ZALOGOWANY } ?>
<?php http://www.php.net/define( 'SALT', '#@r23T@f23NJOąąąĆóŁd;'[:""{:ffs+SD:+@wD#~`ds2' ); $login = http://www.php.net/mysql_real_escape_string( $_POST['login'] ); $haslo = $_POST['haslo']; $haslo = http://www.php.net/md5( $haslo . SALT ); $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() ); if( http://www.php.net/mysql_num_rows( $result ) ) { // ZALOGOWANY } ?>
<?php $login = http://www.php.net/mysql_real_escape_string( $_POST['login'] ); $haslo = $_POST['haslo']; $haslo = http://www.php.net/md5( http://www.php.net/md5( $haslo ) ); $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() ); if( http://www.php.net/mysql_num_rows( $result ) ) { // ZALOGOWANY } ?>
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?
O i taka odpowiedź rozjaśniła mi już wiele.
Teraz tylko muszę dojść do tego, dlaczego sam o tym nie pomyślałem, tylko kombinowałem na około z wykrywaniem kolizji kolizji-32-znakowych
Zakładając teraz, że łotr może założyć sobie konto w danym serwisie i podejrzeć swój własny hash w bazie, może łatwo odgagnąć ile razy hashowane sa hasła. A wtedy to ma już z górki.
Natomiast w przypadku gdy ma tylko cudze hashe i nie wie ile razy została wykonana funkcja md5() może mieć już większe problemy.
hej. zainteresowała mnie ta dyskusja.
mam jedno pytanie, laika w tych sprawach: jak się ma stosowanie metody BF do złamania hasła, jeżeli dodamy w skrypcie ograniczenie max. ilości logowań oraz captchę? czy będzie to miało wpływ jakiś na tą metodę ?
Źle zrobioną captchę łatwo obejść, na dobrą też są już znane sposoby. Ograniczenie ilości logowań jest dobrym pomysłem, o ile oprzemy je o coś, co nie jest łatwo zmienić między dwoma żądaniami (np. adres IP), a nie np. ciastka sesji . Jednak da to efekt tylko, jeśli przeprowadzać będziemy atak na całą witrynę WWW. Jeśli ktoś wejdzie w posiadanie kopii bazy danych, albo samej zawartości tabelki użytkowników (kradzież, włamania, błędy zabezpieczeń), nic nam to nie da, ponieważ atakujący może sobie spokojnie operować na własnym komputerze na gołych danych .
Ja polecam mieszanie hashów - np. md5 + sha256: najpierw shashować za pomocą md5, wyciąć np. pierwsze 7 znaków z powstałego hasha i shashować je metodą sha256, po czym jakoś skleić te ciągi - od 8 znaku do końca z tego z md5, i cały sha256. Można jeszcze te ciągi jakoś pomieszać - np. sha256 przeciąć na pół (lub nierówne części), i jakoś pomieszać powstałe części z tym ciągiem z md5. Biorąc pod uwagę fakt, że każdy programista tym sposobem ustawi sobie inne kombinacje, starsznie trudnym zadaniem byłoby złamanie takiego szyfu
@Apocalyptiq:
Strasznie trudne byłoby odkrycie prawidzwego ciągu wejściowego, natomiast samo złamanie zabezpieczenia byłoby dokładnie takie samo jak w przypadku jednokrotnego haszowania MD5. Ponadto zasugerowana przez ciebie metoda będzie baaardzo obciążająca.
Ale ten test przeprowadziłem dla 100x hashowania - a mało mozliwe, że w tej samej sekundzie będzie chciało nam się zalogować/zarejestrować 100 użytkowników A i hasła wprowadzane przez użytkowników są znacznie prostsze niż ciąg generowny przez uniqid, który zastosowałem w teście.
Ale tak w ogóle, przed czym ma chronić to hashowanie?
Hash osoba trzecia może zdobyć albo przez cookies, jeżeli istnieje na naszej stronie możliwość autologowania, i własnie hasha zapisujemy w ciastkach (np. ktoś w kawiarencie logując się na nasz serwis wybrał, żeby go zapamiętało - ktoś inny siada na tym kompie i wyjmuje hasha z ciastek, no ale w takim przypadku i tak ma dostęp do danego konta ), albo jakoś je wychwycić z bazy - ale jeżeli stosujemy np. PDO i bindujemy wszystkie zmienne, które wprowadza użytkownik (m.in. pochodzące z formularzy), to np. sql injection jest praktycznie jest niemożliwe. Więc po co te hashe?
Chyba że zrobilibyśmy tak, że w profilu, jeżeli ktoś chciałby zmienić hasło/e-mail - wymagane będzie wpisanie aktualnego hasła, wtedy ktoś, kto dostał się na czyjeś konto, a nie zna hasła, danego konta nie przechwyci (nie zmieni hasła). A czy istnieje możliwość edytowania/dodawania sobie w przeglądarce ciastek? Bo jeżeli tak, to możnaby sobie hash z kawiarenki skopiować, w domu utworzyć odpowiednie ciastka z tym hashem, i wtedy działałoby autologowanie.
Żeby hash hasła trzymać w cookie... trzeba być naprawdę geniuszem.
A po co te hashe? Chociażby po to byś Ty przeglądając bazę danych nie znał haseł użytkowników...
A ja to robie inaczej po 10 nie powodzonych probach logowania(mowa o wszystkich nie 10 pod rzad) konto zostaje zbanowane na kilka minut i tyle i jak ktos chce moze sobie robic brute-force a hasla hashuje samym md5() i tyle.
Mowi sie trudno cos za cos zreszta nie jest to portal taki jak php.pl wiec no problem a poki ktos nie sproboje to o tym nie wie.
A żebyś wiedział... opór materii jest niesamowity.
Apocalyptiq -> no i co Ci przychodzi z takiego cudacznego zabezpieczenia? Skoro zdobędę dostęp do bazy, prawdopodobnie kwestią czasu jest także uzyskanie dostępu do kodu źródłowego. Jak ty się bawisz w sklejanie, mi wystarczy prosta nakładka na moją bazę haseł opracowana na podstawie Twojego kodu, by Twoje dodatki ominąć i po kłopocie. Era tajnej kryptografii skończyła się 30 lat temu. Era amatorskiej kryptografii jeszcze wcześniej. Nad funkcjami mieszającymi siedzą najlepsi matematycy świata. Szansa, że na chybił trafił ktoś stworzy coś lepszego, jest bliska zeru - w zdecydowanej większości przypadków tylko pogarszacie sprawę.
http://www.zyxist.com/pokaz.php/wielokrotne_haszowanie - polecam do przeczytania
A następną osobę, która w tym temacie będzie chciała wyskoczyć z kolejnym "genialnym" pomysłem na podwójne zahaszowanie haseł czy ich pomieszanie, proszę, żeby przeczytała kilka powyższych postów.
Czyli równie dobrze można nie kodować haseł ;-) bo zakładając że hacker dostanie i bazę i źródło kodowanie mieszanie md5 i sha1 + sól etc to i tak złamie hasło.
Już napisałem "pare" postów wyżej że są 3 przypadki "ataku" i hashowanie ma sens tylko w 2 z nich. Natomiast sam kiedyś wszedłem w posiadanie tabelki users pewnego serwisu (przez przypadek) pomimo ze nie mogłem/nie chciałem mieć dostępu do kodu źródłowego.
Ale z czystej ciekawości puściłem słownik + md5 na hasła z 400 userów "odgadłem" około 40 z czego pięć haseł to było "kasia" albo coś w tym stylu ile z tych haseł było tymi samymi hasłami co do poczty nie wiem :] ale od tamtej pory nikt nie wmówi mi że dodawanie soli do hasła jest bez sensu. Ostatnio naszła mnie taka myśl :] ... hasło każdy z userów może dać sobie dupa13 ale login musi być unikalny .... oczywiście metody typu md5($login.$haslo) są pewnie wszystkim znane i szeroko stosowane ale może roll(md5(haslo), strlen($login)). itp itd. możliwości jest wiele.
n-hashowanie nie zwiększa możliwości wygenerowania kolizji n razy tylko do n-tej!
Oznacznmy ilość ciągów o długości 32 znaków generujących ten sam hash przez m.
Dla pierwszego stopnia m ciągów o długości 32 znaków.
Dla każdego ciągu o tym samym hashu pierwszego stopnia istnieje kolejnych m ciągów o tym hashu.
Itd.
Czyli dostajemy ładne drzewko, w którego ostatnim stopniu mamy m^n 32 bajtowych ciągów które wygenerują żądany hash po n-krotnym shashowaniu.
Ktoś napisze że szukanie tych 32-bajtowych ciągów zajmie wieczność, jednak każdy z nich ma prawdopodobnie ileśtam krótszych kolizji.
Tak więc zamiast szukać kolizji z jednym hashem, haker będzie szukał kolizji z m^n hashami.
Co prawda założyłem że kolizyjne hashe się nie powtarzają w ramach jednego stopnia, oraz że dla każdego hasha istnieje tyle samo kolizji o długości =32. O ile drugie założenie się uśredni, o tyle pierwsze nieco zawyża wynik.
Uważam że o wiele sensowniejszym rozwiązaniem jest używanie soli, które uniemożliwi używanie rainbow tables, i nie odsłoni skryptu na ataki brute-force. Ponadto, lepiej używać algorytmów mocniejszych niż md5. Jeżeli hosting nie oferuje hashowania sha1, można takie wkleić w postaci kodu php, lub zrzucić na bazę danych. Jeżeli ta jest w sieci wewnętrznej względem serwera php, szanse podsłuchania przesyłania hasła od klienta do php, będą takie same jak z php do SQL (chyba że ta pierwsza idze po SSL, ale jak jest SSL to rzadko kiedy nie ma sha1).
1. Nie ma sensu wielokrotne haszowanie ani używanie nie wiadomo jakich algorytmów w tym celu
2. Ma sens natomiast solenie, nawet najprostsze, na wypadek, gdyby ktoś przechwycił hasz i chciał skorzytać ze słownika
Nie wiem czy została podana jedna - chyba najważniejsza własność metody sh1 i odciacie losowych 4 znakow - oczywiscie stałych dla każdego hasła
Zwiększa się ryzyko że hasło się powtórzy to prawda - ale jeżeli ktoś wyciągnie potem hashe z naszej bazy - to mu nic szczerze nie dadza, nawet jeżeli będzie wiedział które liczby wycielismy i czym hashujemy, to musi powstawiać losowe zmienne do hasha, a potem b-f dojść do wszystkich kombinacji tych hashy (dla przykładu podam, że hash wyglądał by wtedy np tak. [$j]E[$i]6#[$k]w9a3^[$g] - myślę, że niewielu osobą by się to chciało, kiedy możliwość że trafi na hasło osoby która użyła tego samego loginu i hasła jest niewielka (np dodanie przy rejestracji informacji że musi zostać podany w haśle jeden znak specjalny, inaczej nie przejmuje rejestracji - to jest chyba najlepsza metoda - aby wymusić na userze podanie skomplikowanego hasła.)
Ave
ciekawy temat i chetnie sie tu wypowiem. i chociaz nie znam sie na tym najlepiej, to chyba warto odswiezyc temat
po1 trzeba rozgraniczyc pod jakim katem rozstrzygamy zabezpieczenia hasla
przede wszystkim uwazam, ze nalezy uswiadamiac uzytkownikom jak wazne jest tworzenie skomplikowanych hasel na poziomie odpowiednim do waznosci odpowiadajacym tym haslom kont. i jak ktos wczesniej juz wspomnial mnostwo osob posiada banalnie proste slowa lub imiona jako hasla, o dlugosci zazwyczaj 5, 6 znakow, rzadziej 4 lub 7. malo tego uzywa jednego hasla do wszystkiego [sic!] wiem to z doswiadczenia, bo od lata pomagam ludziom przy prostych sprawach zwiazanych z kompem i jak oni zakladaja nowe konta i pisze 'podaj email: ____ haslo: ____' to podadza haslo do wlasnego mejla.... zenujace, ale prawdziwe. dlatego jeszcze raz powtorze jak wazne jest wpajanie ludziom tej podstawowej wiedzy dot. bezpieczenstwa kont.
uwazam, ze podstawy to: minimalna dlugosc hasla, nie zawieranie loginu, zawierajace cyfry, duze litery oraz inne znaki "£$%^&* w roznych miejscach, a nie np kasia123 etc i chyba lepiej zapisac sobie na kartce wazne haslo i trzymac gdzies w domu, niz wybrac proste haslo i je pamietac
druga rzecz to zabezpieczenie dostepu z poziomu aplikacji.
tutaj zabezpiecza sie haslo uzytkownika, bo jesli ktos uzyskal dostep do mechanizmu szyfrujacego, to jesli jest on jednostronny, uwazam, ze standardem powinno byc dodawanie soli indywidualnej dla kazdego uzytkownika, bazujacego na jego danych. bardzo moze to utrudnic lub wrecz uniemozliwic dostep do prawdziwego hasla.
wielkrotne hashowanie? chociaz rowniez nie zaglebiam sie w tajniki algorytmow hashujacych wydaje mi sie, ze wielokrotne hashowanie zwieksza mozliwosci kolizji. w jakim stopniu, to nie bede zgadywal, bo to sie mija z celem. jesli ktos zdobedzie hash, to moze uzyc bazy, ktore zawieraja 2 czy 3 krotne hashe. i to sie mija z celem, bo naprawde lepiej jest uzyc soli. moze sie myle, ale chyba nie ma zadnych minusow ich uzywania?
mamy oczywiscie ograniczona liczbe hashow. przeprowadzajac wielokrotne [nieskonczone] hashowania moga doprowadzic nas chyba tylko do zapetlenia - po x hashowaniach otrzymamy taki sam hash jaki mielismy wczesniej. podejrzewam, ze mozna czesc [1/4? 1/8?] hashy odrzucic, ktorych zaden ciag znakow nie wygeneruje.
napisalem 'chyba tylko do zapetlenia', bo chociaz praktycznie odrzucam calkowicie te opcje, to moja niewiedza nie pozwala mi jej obalic - okreslony ciag znakow wygeneruje hash identyczny temu ciagowi znakow. to by byl po prostu lol ;p
nalezy pamietac tez o tym, ze crackerzy znaja sie na tym lepiej niz my, a co dopiero szaraczki tworzace hasla. i nawet jesli wymagamy ^[a-zA-Z0-9!"£$%^&*()]{10-20}$ do hasla to wg 'poradnikow' do hasel ktos wymysli jestem basia i zamieni Je$+emKa$14 czy cos podobnego, to hackerek znajac wymagania nie bedzie sie poslugiwal bf, ale zlamie te osobe i wygeneruje slownik, bo bedzie wiedzial, ze ludzie zazwyczaj zamieniaja znaki na inne konkretne.
nie zrozumcie mnie zle - uwazam, ze ow haslo jest o niebo lepsze od kasia ;ppp
wspomnialem wczesniej o mozliwosci dwustronnego szyfrowania. nie chodzi moze tutaj tyle o hasla co o rozne dane, ktore powinny byc kodowane. wtedy znow sol sie pojawia i chyba jest niezastapiona ;p
co do porzedniego postu:
z tego co [nie] wiem to sha0 i 1 podobnie jak md4 i 5 generuja wyniki zawierajace znaki ze zbioru {0-9a-f} czyli 16^4 to 64k kombinacji, co wydaje sie banalna liczba do podstawienia, zeby uzyskac slowo kolizji i uzyskac dostep. w takim wypadku sol tez nie pomoze, bo jesli ktos zna algorytm, to zna i sol, czyli tez moze dojsc do poczatkowego hasla
i na koniec, tak na rozweselenie
co powiedzie na haslo typu '¬' w sensie jeden jakis dziwny znak, ktory nie nalezy do zbioru znakow alfanumerycznych. oczywiscie jak ktos idzie porzadnie na bf, to zacznie od poczatku, ale co jesli ktos chce zaoszczedzic troche czasu i zacznie od hasel 3-znakowych? ;p
MD5 ma 16^32 możliwych kombinacji.
Hasła typu: 't¬sdમﬗ' IMO rozwiązują problem ataku typu BF, ale powodzenia życzę w nakłonieniu ludzi do stosowania takiego hasła
Osobiście polecam stosowanie crypt().
Wszystkie metody hashowania które podaliście powyżej, są metodami jednostronnymi, więc w czystej teorii NIE MA możliwości odkodowania nawet pojedynczo zahashowanego hasła. Jednak Rainbow Tables (tablice tęczowe) pokazuje że odkodowanie (w sposób dość nietypowy, ale zawsze ) takiego hasha jest jak najbardziej możliwe. Przed tą metodą teoretycznie możemy się zabezpieczyć hashując dwukrotnie, ale MUSICIE pamiętać, że hashując na md5 chociażby 28-znakowy wynik sha1, zwiększamy ilość kombinacji które w wyniku dadzą nam ten sam ciąg md5 :-). Wiem że trafienie na drugi taki sam ciąg jawny, który da tam w wyniku ten sam hash md5 jest jak szóstka w totolotku 3x pod rząd, ale skoro mówimy tu o bezpieczeństwie metod hashujących, to są lepsze metody.
Tablice tęczowe są z kolei zbiorem hashy wygenerowanym za pomocą swoistego brute-force.
Wyglądają one mniej więcej tak:
a 0cc175b9c0f1b6a831c399e269772661
b 92eb5ffee6ae2fec3ad71c777531578f
c 4a8a08f09d37b73795649038408b5f33
(...)
aa 4124bc0a9335c27f086f24ba207a4912
ab 187ef4436122d1cc2f40dc2b92f0eba0
ac e2075474294983e013ee4dd2201c7a73
(...)
I wierzcie mi, że trafiłem na kilka online'owych skryptów które potrafiły odhashowały mi np. hasło brzmiące "dw00jka" - kto z nas nie używa czasem tego typu haseł?
A co jest takiego cudownego z funkcją crypt() ? I dlaczego jest taka bezpieczna? Zaraz podam Wam przykład.
Oto przykładowe hashe crypta:
a - $1$sxKPdmqP$BHtXNcPix.QTIDAWgozat0
a - $1$d7h5X5sH$VzC4/sM4.FM1624O0Kd7I1
a - $1$ED8ONypj$gSpKFzkcSae1hXVnrf7Cq.
Jak widać powyżej, crypt() jest algorytmem wykorzystującym losowość. Wyobraźcie sobie, jak rainbow tables miałoby sobie z tym fantem poradzić . Pytanie pewnie pojawi się, jak przy tym cholerstwie napisać funkcję porównującą hasło z hashem, skoro hash jest losowy ?
Sprawa jest prosta:
Nie wiem czy zmiana soli po zalogowaniu ma duży sens, spowalnia to (lekko, ale zawsze) - działanie programu. Sądzę że losowe ziarna dla poszczególnych użytkowników, nawet z określonej puli, mają większy sens. Choć o czym my rozmawiamy, jeśli ktoś robi WP, może jest sens na to zrwacać uwagę, ale w przypadku mniejszych portali sądzę że kodowanie do (sha1 + ziarno) i ponowne zakodowanie starczy zupełnie...
Mikz -> crypt() to nie żaden algorytm, tylko uniwersalna funkcja dostępowa do kilku znanych algorytmów występujących zależnie od systemu, implementacji itd. - wśród nich jest m.in. MD5. Tak samo jedyna losowość, jaka tam występuje, to generowanie soli i nie ma to nic wspólnego z losowością samego algorytmu. Inaczej by się z tego w ogóle korzystać nie dało .
crypt() działa na takiej zasadzie, że jeśli wywołane jest z jednym argumentem, generuje losową sól zwraca hasz z doklejoną solą. Możemy także sól określić jawnie i to jest wykorzystywane przy sprawdzaniu hasła. Podajemy wtedy zahaszowany ciąg, ponieważ do niego doklejona jest sól i funkcja może sobie z niego ją odczytać. Nie ma w tym żadnej magii, to samo można uzyskać, jawnie określając algorytm haszujący:
Zyx -> z tą solą to chyba dość oczywiste, ale dopóki jest ona generowana losowo, dopóty można powiedzieć że jest wykorzystywana losowość przy generowaniu hasha.
Jeśli chodzi o tablice tęczowe, wiem mniej więcej na czym one polegają i chyba swoim opisem nie odbiegłem daleko od ich istoty .
Jednak kiedy odrzucimy możliwość skorzystania z rainbow tables przy jednostronnym hashu (właśnie za pomocą tej "losowości" crypta), wtedy można swobodnie stwierdzić że nie ma realnej szansy na złamanie takiego hasha, więc jest on bezpieczny.
Podwójne hashowanie staje się w tym momencie po prostu zbędne .
Ja w przyplywie entuzjazmu bawie sie innaczej baza danych oczywiscie z tym ze haslo zapisze sobie w kolumnie dajmy na to lastlogin a w kolumnie pass przechowam sobie jakis random z literek i cyferek i wiem ze predzej czy pozniej ktos sie odpowiednio zreflektuje daj im odpowiednio duzo czasu a wszedzie sie dostana. Kwestia druga jest taka ze im wiecej zabezpieczen tym mniejsza wydajnosc i nie wydaje mi sie ze sztuka jest zrobic aplikacje do ktorej sie nikt nie wlamie sztuka jest dobrze to wywazyc, aby jednak wiedziec jak to wywazyc mysle ze trzeba monitorowac ruch... i postawic kilka sprytnych alertow. Osobisie ostatnio bawie sie sesjami zamieniam ich id po kazdym wywolaniu, kontrola ip, kontorla przegladarki i rozne takie bajery ktore napewno obnizaja wydajnosc aplikacji i nie zawsze sa konieczne. Mysle rowniez ze optymalizacja js tez jakos podnosi bezpieczenstwo kod w jednym ciagu i nazwy funkcji/zmiennych typu a1,a2 etc.. moga szybko zniechecic md5 to nie wszystko a jak ktos bedze bardzo chcial to i z tym sobie poradzi... do kwestji zabezpieczen podchodze jak do zabawy a jesli komus uda sie odczytac 32 z bazy danych w kolumnie pass po zlamaniu hasha moze sie okazac ze nic z tego nie wyniknie tylko dlatego bo hash byl przechowywany w bazie na wspak... troche wyobrazni paniowie...
Ja za to zabezpieczam się odrobiną sztucznej inteligencji i firewallem - wystarcza w zupełności. Oczywiście baza danych stoi na innym serwerze, php stoi na VPS'ach a uprawnienia do bazy danych są tak dobrane, że użytkownik nie ma możliwości odczytu hasła (są odpowiednie funkcje służące sprawdzaniu poprawności oraz zmianie.
To jak do tej pory wystarczyło a nie żadne hashowanie wielokrotne.
3 grosze..
jak ktos zna aplikacje TrueCrypt to odsylam do specjalistow, do ich dokumentacji o wielokrotnym hashowniu, najbardziej zalecana metoda to wlasnie wielokrotne hashowanie przy uzyciu bodajze 3 algorytmow
mozna tez zobaczyc krotkie opisy kazdej metody wielokrotnego hashowania w okienku wyboru metody hashowania partycji lub wyboru klucza, nie pamietam dokladnie, tam sa krotkie opisy dlczago i ktora jest rekomendowana
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 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?
Hm, ale ten mój pomysł miałby uniemożliwić dojście do hasła za pomocą dostępnych w necie baz danych z rozshashowanymi hashami. Wtedy musieliby sobie sami zrobić tablicę od nowa dla danego klucza :-) A że pozna klucz - możnaby własnie w bazie zapisywać te losowe klucze, wtedy nawet jakby je znał, musiałby dla każdego hasła utworzyć osobną tablicę tęczową, a takie coś to już byłby wyczyn Orientuje się ktoś ile czasu wymaga utworzenie takiej tablicy tęczowej lub takie bazy danych, jakie są dostępne w necie (wpisujemy hash i dostajemy hasło, z którego został wygenerowany)?
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.
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ć
Pozdrawiam,
Łukasz
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ę!
slownik/brute-force
Problemem jest mała inwencja użytkowników przy wymyślaniu haseł
c) rainbow
Problemem jest generalnie brak "soli" 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
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.
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
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:
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ę:
<!-- Link : example.com/form.php?hash=9812asd65017578gs23487 --> <form action="" method="POST"> <input type="text" value="<?php $_GET['hash']; ?>"> </form>
A co myślicie by zrobić własne hashowanie ?
Funkcja str_replace
A czy przeczytałeś w ogóle ten temat...?
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
http://www.codinghorror.com/blog/2012/04/speed-hashing.html
Bcrypt: php manual -> crypt
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:
$authAdapter = new Zend_Auth_Adapter_DbTable( Zend_Db_Table::getDefaultAdapter(), "users", "email", "md5", "SHA1(CONCAT('" . Zend_Registry::get('salt') . "', ?, salt))");
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ć
Zawsze offtopowałem ^^.
A do tematu:
Można zrobić coś takiego, myślę że to coś da
<? $rand = http://www.php.net/rand(1,11); $dodatek = http://www.php.net/md5($rand); $haslo = 'megatajne123'; $hashcalk = http://www.php.net/md5($rand, $haslo); http://www.php.net/echo $hashcalk; ?>
<? $rand = http://www.php.net/rand(1,11); $dodatek = http://www.php.net/md5($rand); $haslo = 'megatajne123'; $hashcalk = http://www.php.net/md5($rand, $haslo); http://www.php.net/echo $hashcalk; ?>
To na dobrą sprawę jest nic innego, jak
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ć.
http://www.php.net/md5(http://www.php.net/rand(1, 11), true);
A ogarnijcie to:
<? function hash($string) { $hashe = http://www.php.net/array( "sha512","ripemd128","ripemd256","ripemd320","whirlpool", "tiger128,3","tiger160,3","tiger192,3","tiger128,4","tiger160,4", "tiger192,4","snefru","gost","adler32","crc32","crc32b"); foreach($hashe as $hash) { hash($hash, $string); } return $string; } ?>
<? function hash($string) { $hashe = http://www.php.net/array( "sha512","ripemd128","ripemd256","ripemd320","whirlpool", "tiger128,3","tiger160,3","tiger192,3","tiger128,4","tiger160,4", "tiger192,4","snefru","gost","adler32","crc32","crc32b"); foreach($hashe as $hash) { hash($hash, $string); } return $string; } ?>
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
Nie lepiej zrobić coś takiego?
$haslo = "Konstantynopolitańczykówianeczka"; $hash = hash(http://www.php.net/md5,$haslo); for($i=1;$i<=10000;$i++) { $hash = hash(sha1,$hash); } http://www.php.net/echo $hash;
@Przemek19 Polecam przeczytac ten temat od poczatku. Masz tam wyjasnione czemu twoja metoda jest totalnie do bani i totalnie niebezpieczna
Ok, miałem 2 minuty, więc nie doczytałem
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)