Czy hashowanie dwa razy przed przechowywaniem jest mniej lub bardziej bezpieczne niż jednorazowe hashowanie?
Mówię o tym:
$hashed_password = hash(hash($plaintext_password));
zamiast tego:
$hashed_password = hash($plaintext_password);
Jeśli jest mniej bezpieczny, czy możesz podać dobre wyjaśnienie (lub link do jednego)?
Czy używana funkcja skrótu ma znaczenie? Czy robi to różnicę, jeśli miksujesz md5 i sha1 (na przykład) zamiast powtarzać tę samą funkcję skrótu?
Uwaga 1: Kiedy mówię „podwójne haszowanie”, mówię o haszowaniu hasła dwukrotnie, aby uczynić go bardziej zaciemnionym. Nie mówię o technice rozwiązywania kolizji .
Uwaga 2: Wiem, że muszę dodać losową sól, aby naprawdę była bezpieczna. Pytanie brzmi, czy mieszanie dwukrotnie tym samym algorytmem pomaga, czy boli hash.
security
hash
passwords
cryptography
password-hash
Bill jaszczurka
źródło
źródło
Hash(password)
iHash(Hash(password))
są równie niepewni. Obaj nie mają pojęcia bezpieczeństwa semantycznego . Oznacza to, że wynik można odróżnić od losowej. Na przykładMD5("password")
jest5f4dcc3b5aa765d61d8327deb882cf99
. Wiem, że to hash MD5password
, a to jest odróżnić od losowych. Zamiast tego powinieneś użyć HMAC. Jest to możliwe do udowodnienia bezpieczeństwo i jego PRF.Odpowiedzi:
Jednorazowe haszowanie hasła jest niepewne
Nie, wiele skrótów nie jest mniej bezpieczne; są istotną częścią bezpiecznego używania hasła.
Iteracja skrótu wydłuża czas atakującego na wypróbowanie każdego hasła na liście kandydatów. Możesz łatwo wydłużyć czas potrzebny do zaatakowania hasła z kilku godzin na lata.
Prosta iteracja nie wystarczy
Zwykłe łączenie danych wyjściowych mieszania z danymi wejściowymi nie jest wystarczające dla bezpieczeństwa. Iteracja powinna odbywać się w kontekście algorytmu, który zachowuje entropię hasła. Na szczęście istnieje kilka opublikowanych algorytmów, które poddano wystarczającej kontroli, aby dać pewność co do ich projektu.
Dobry algorytm wyprowadzania klucza, taki jak PBKDF2, wstrzykuje hasło do każdej rundy mieszania, łagodząc obawy dotyczące kolizji w wyniku mieszania. PBKDF2 może być używany do uwierzytelniania hasłem bez zmian. Bcrypt śledzi wyprowadzenie klucza z krokiem szyfrowania; w ten sposób, jeśli zostanie wykryty szybki sposób na odwrócenie wyprowadzania klucza, atakujący nadal musi wykonać atak znanego tekstu jawnego.
Jak złamać hasło
Przechowywane hasła wymagają ochrony przed atakiem offline. Jeśli hasła nie są solone, można je złamać za pomocą wstępnie obliczonego ataku słownikowego (na przykład przy użyciu Tęczowej tabeli). W przeciwnym razie atakujący musi poświęcić czas na obliczenie skrótu dla każdego hasła i sprawdzenie, czy pasuje ono do przechowywanego skrótu.
Wszystkie hasła nie są jednakowo prawdopodobne. Atakujący mogą wyczerpująco przeszukiwać wszystkie krótkie hasła, ale wiedzą, że ich szanse na sukces brutalnej siły gwałtownie spadają z każdą dodatkową postacią. Zamiast tego używają uporządkowanej listy najbardziej prawdopodobnych haseł. Zaczynają się od „password123” i przechodzą do rzadziej używanych haseł.
Powiedzmy, że lista atakujących jest długa, z 10 miliardami kandydatów; załóżmy również, że system komputerowy może obliczyć 1 milion skrótów na sekundę. Atakujący może przetestować całą listę na mniej niż trzy godziny, jeśli zastosowana zostanie tylko jedna iteracja. Ale jeśli zastosuje się tylko 2000 iteracji, czas ten wydłuży się do prawie 8 miesięcy. Aby pokonać bardziej wyrafinowanego atakującego - na przykład zdolnego do pobrania programu, który może wykorzystać moc swojego GPU - potrzebujesz więcej iteracji.
Jak duzo wystarczy?
Liczba iteracji do wykorzystania jest kompromisem między bezpieczeństwem a wygodą użytkownika. Specjalistyczny sprzęt, z którego mogą korzystać osoby atakujące, jest tani, ale wciąż może wykonywać setki milionów iteracji na sekundę. Wydajność systemu atakującego decyduje o tym, ile czasu zajmuje złamanie hasła przy danej liczbie iteracji. Ale Twoja aplikacja prawdopodobnie nie używa tego specjalistycznego sprzętu. Ile iteracji możesz wykonać bez obciążania użytkowników, zależy od twojego systemu.
Prawdopodobnie możesz pozwolić użytkownikom czekać około extra sekundy podczas uwierzytelniania. Profiluj platformę docelową i używaj tyle iteracji, ile możesz sobie pozwolić. Platformy, które przetestowałem (jeden użytkownik na urządzeniu mobilnym lub wielu użytkowników na platformie serwerowej) mogą wygodnie obsługiwać PBKDF2 z 60 000 do 120 000 iteracji lub bcrypt o współczynniku kosztu 12 lub 13.
Więcej tła
Przeczytaj PKCS # 5, aby uzyskać wiarygodne informacje na temat roli soli i iteracji w mieszaniu. Mimo że PBKDF2 był przeznaczony do generowania kluczy szyfrowania z haseł, działa dobrze jako jednokierunkowy skrót do uwierzytelniania hasła. Każda iteracja bcrypt jest droższa niż skrót SHA-2, więc możesz użyć mniejszej liczby iteracji, ale idea jest taka sama. Bcrypt wykracza także poza większość rozwiązań opartych na PBKDF2, używając klucza pochodnego do szyfrowania znanego zwykłego tekstu. Powstały tekst zaszyfrowany jest przechowywany jako „skrót” wraz z niektórymi metadanymi. Jednak nic nie stoi na przeszkodzie, abyś zrobił to samo z PBKDF2.
Oto inne odpowiedzi, które napisałem na ten temat:
źródło
Ci, którzy twierdzą, że jest bezpieczny, ogólnie mają rację . „Podwójne” mieszanie (lub logiczne rozwinięcie tego, iteracja funkcji skrótu) jest absolutnie bezpieczne, jeśli jest wykonane właściwie , z uwagi na konkretny problem.
Tym, którzy twierdzą, że jest niepewna, mają rację w tym przypadku . Kod opublikowany w pytaniu jest niepewny. Porozmawiajmy o tym, dlaczego:
Istnieją dwie podstawowe właściwości funkcji skrótu, które nas niepokoją:
Pre-Image Resistance - Biorąc pod uwagę skrót
$h
, znalezienie$m
takiego komunikatu powinno być trudne$h === hash($m)
Odporność na drugie zdjęcie wstępne - biorąc pod uwagę wiadomość
$m1
, znalezienie innej wiadomości$m2
takiej jak ta powinno być trudnehash($m1) === hash($m2)
Odporność na kolizje - znalezienie
($m1, $m2)
takich wiadomości powinno być trudnehash($m1) === hash($m2)
(należy pamiętać, że jest to podobne do odporności na drugie zdjęcie wstępne, ale różni się tym, że tutaj atakujący kontroluje obie wiadomości) ...Jeśli chodzi o przechowywanie haseł , wszystko, na czym nam zależy, to Odporność na obraz wstępny . Pozostałe dwa byłyby dyskusyjne, ponieważ
$m1
to hasło użytkownika staramy się chronić. Więc jeśli atakujący już go ma, skrót nie ma nic do ochrony ...ZRZECZENIE SIĘ
Wszystko, co następuje, opiera się na założeniu, że wszystkim, na czym nam zależy, jest odporność na obraz wstępny . Pozostałe dwie podstawowe właściwości funkcji skrótu mogą nie (i zwykle nie) utrzymywać się w ten sam sposób. Tak więc wnioski zawarte w tym poście mają zastosowanie tylko w przypadku używania funkcji skrótu do przechowywania haseł. Nie mają one ogólnie zastosowania ...
Zacznijmy
Na potrzeby tej dyskusji wymyślmy naszą własną funkcję skrótu:
Teraz powinno być całkiem oczywiste, co robi ta funkcja skrótu. Sumuje wartości ASCII każdego znaku wejściowego, a następnie przyjmuje modulo tego wyniku z 256.
Przetestujmy to:
Zobaczmy teraz, co się stanie, jeśli uruchomimy go kilka razy wokół funkcji:
To daje:
Hm, wow. Wygenerowaliśmy kolizje !!! Spróbujmy sprawdzić, dlaczego:
Oto wynik mieszania ciągu każdego możliwego wyniku mieszania:
Zwróć uwagę na tendencję do wyższych liczb. To okazuje się naszym martwym punktem. Uruchomienie skrótu 4 razy ($ hash = ourHash ($ hash) `, dla każdego elementu) kończy się dając nam:
Mamy zwęziły się w dół do 8 wartości ... To zły ... Nasza pierwotna funkcja odwzorowywane
S(∞)
naS(256)
. To jest stworzyliśmy suriekcją funkcji mapowania$input
do$output
.Ponieważ mamy funkcję Surjective, nie mamy gwarancji, że mapowanie dla dowolnego podzbioru danych wejściowych nie będzie miało kolizji (w rzeczywistości tak się stanie).
Tak się tutaj stało! Nasza funkcja była zła, ale nie dlatego to działało (dlatego działało tak szybko i tak całkowicie).
To samo dzieje się z
MD5
. MapujeS(∞)
naS(2^128)
. Ponieważ nie ma gwarancji, że działanieMD5(S(output))
będzie Iniektywne , co oznacza, że nie spowoduje kolizji.Sekcja TL / DR
Dlatego, ponieważ podawanie danych wyjściowych z powrotem
md5
bezpośrednio może generować kolizje, każda iteracja zwiększy prawdopodobieństwo kolizji. Jest to jednak wzrost liniowy, co oznacza, że chociaż zestaw wyników2^128
jest zmniejszony, nie jest on wystarczająco szybko redukowany, aby być krytyczną wadą.Więc,
Im więcej razy iterujesz, tym bardziej idzie redukcja.
Poprawka
Na szczęście dla nas istnieje trywialny sposób, aby to naprawić: przekaż coś w dalszych iteracjach:
Zauważ, że dalsze iteracje nie są 2 ^ 128 dla każdej wartości dla
$input
. Oznacza to, że możemy być w stanie wygenerować$input
wartości, które nadal zderzają się wzdłuż linii (a tym samym ustabilizują się lub rezonują przy znacznie mniejszych niż2^128
możliwe wyjściach). Ale ogólny przypadek$input
jest nadal tak silny, jak w przypadku pojedynczej rundy.Czekaj, prawda? Przetestujmy to za pomocą naszej
ourHash()
funkcji. Przełączam na$hash = ourHash($input . $hash);
, dla 100 iteracji:Nadal istnieje tam szorstki wzór, ale zauważ, że nie jest to bardziej wzór niż nasza podstawowa funkcja (która była już dość słaba).
Zauważ jednak, że
0
i3
stał kolizji, choć nie były one w jednym przebiegu. Jest to zastosowanie tego, co powiedziałem wcześniej (że odporność na kolizje pozostaje taka sama dla zestawu wszystkich danych wejściowych, ale określone trasy kolizji mogą się otworzyć z powodu wad w podstawowym algorytmie).Sekcja TL / DR
Dostarczając dane wejściowe do każdej iteracji, skutecznie przełamujemy wszelkie kolizje, które mogły wystąpić w poprzedniej iteracji.
Dlatego
md5($input . md5($input));
powinien być ( przynajmniej teoretycznie ) tak silny jakmd5($input)
.Czy to ważne?
Tak. Jest to jeden z powodów, dla których PBKDF2 zastąpił PBKDF1 w RFC 2898 . Rozważ wewnętrzne pętle dwóch:
PBKDF1:
Gdzie
c
jest liczba iteracji,P
hasło iS
sólPBKDF2:
Gdzie PRF to tak naprawdę tylko HMAC. Ale dla naszych celów tutaj powiedzmy tylko
PRF(P, S) = Hash(P || S)
(to znaczy, że PRF 2 danych wejściowych jest taki sam, z grubsza mówiąc, jak skrót z dwoma połączonymi razem). Tak bardzo nie jest , ale tak jest dla naszych celów.Tak więc PBKDF2 utrzymuje odporność na zderzenia
Hash
funkcji bazowej , a PBKDF1 tego nie robi.Wiązanie wszystkiego razem:
Wiemy o bezpiecznych sposobach iteracji skrótu. W rzeczywistości:
Zazwyczaj jest bezpieczny.
Teraz, aby dowiedzieć się, dlaczego chcielibyśmy go haszować, przeanalizujmy ruch entropii.
Hash pobiera zestaw nieskończony:
S(∞)
i tworzy mniejszy zestaw o stałej wielkościS(n)
. Następnej iteracji (zakładając, że wejście jest przekazywana z powrotem w) mapyS(∞)
naS(n)
raz:Zauważ, że końcowy wynik ma dokładnie taką samą ilość entropii jak pierwszy . Iteracja nie „sprawi, że będzie bardziej zaciemniona”. Entropia jest identyczna. Nie ma magicznego źródła nieprzewidywalności (jest to funkcja pseudolosowa, a nie funkcja losowa).
Jest jednak korzyść z iteracji. Powoduje to sztucznie spowolnienie procesu mieszania. I dlatego iteracja może być dobrym pomysłem. W rzeczywistości jest to podstawowa zasada najnowocześniejszych algorytmów haszujących hasła (fakt, że robienie czegoś w kółko spowalnia go).
Powolność jest dobra, ponieważ walczy z podstawowym zagrożeniem bezpieczeństwa: brutalnym wymuszaniem. Im wolniej wprowadzamy algorytm mieszania, tym trudniejsi atakujący muszą pracować, aby atakować skradzione nam hasła. I to dobrze!
źródło
$output = md5($output); // < 2^128 possibilities
--- czy to naprawdę surowe<
, czy<=
?md5()
w tym przypadku), aby naprawdę wiedzieć. Ale ogólnie będzie<
i nie<=
... Pamiętaj, mówimy o wielkości zestawu$output
dla wszystkich możliwych$inputs
. Więc jeśli mamy jeszcze jedną kolizję to będzie<
, dlatego<
jest lepiej generalizer.Tak, ponowne mieszanie zmniejsza przestrzeń wyszukiwania, ale nie, to nie ma znaczenia - skuteczne zmniejszenie jest nieznaczne.
Ponowne mieszanie wydłuża czas potrzebny na brutalną siłę, ale robienie tego tylko dwa razy jest również nieoptymalne.
To, czego naprawdę chcesz, to haszować hasło za pomocą PBKDF2 - sprawdzonej metody używania bezpiecznego skrótu z solą i iteracjami. Sprawdź tę odpowiedź SO .
EDYCJA : Prawie zapomniałem - NIE UŻYWAJ MD5 !!!! Użyj nowoczesnego skrótu kryptograficznego, takiego jak rodzina SHA-2 (SHA-256, SHA-384 i SHA-512).
źródło
Tak - zmniejsza liczbę możliwych ciągów pasujących do ciągu.
Jak już wspomniałeś, solone hasze są znacznie lepsze.
Artykuł tutaj: http://websecurity.ro/blog/2007/11/02/md5md5-vs-md5/ , próbuje udowodnić, dlaczego jest równoważny, ale nie jestem pewien co do logiki. Częściowo zakładają, że nie ma dostępnego oprogramowania do analizy md5 (md5 (tekst)), ale oczywiście tworzenie tablic tęczowych jest dość trywialne.
Nadal trzymam się mojej odpowiedzi, że liczba skrótów typu md5 (md5 (tekst)) jest mniejsza niż skrótów md5 (tekst), co zwiększa prawdopodobieństwo kolizji (nawet jeśli jest to mało prawdopodobne) i zmniejsza przestrzeń wyszukiwania.
źródło
Większość odpowiedzi pochodzi od osób bez doświadczenia w dziedzinie kryptografii lub bezpieczeństwa. I są w błędzie. Użyj soli, jeśli to możliwe, unikalnej dla każdego rekordu. MD5 / SHA / etc są zbyt szybkie, wręcz przeciwnie, niż chcesz. PBKDF2 i bcrypt są wolniejsze (co jest dobre), ale można je pokonać za pomocą układów ASIC / FPGA / GPU (obecnie bardzo przystępnych). Potrzebny jest więc algorytm wymagający dużej ilości pamięci: wpisz scrypt .
Oto świeckie wyjaśnienie soli i szybkości (ale nie algorytmów wymagających dużej pamięci).
źródło
Patrzę na to z praktycznego punktu widzenia. Po czym jest haker? Dlaczego kombinacja znaków, która po przejściu przez funkcję skrótu generuje pożądany skrót.
Zapisujesz tylko ostatni hash, dlatego haker musi brutalnie wymusić tylko jeden hash. Zakładając, że masz mniej więcej takie same szanse natknięcia się na pożądany skrót z każdym krokiem brutalnej siły, liczba skrótów jest nieistotna. Możesz wykonać milion iteracji skrótu, a to nie zwiększy ani nie zmniejszy bezpieczeństwa, ponieważ na końcu linii jest jeszcze tylko jeden skrót do złamania, a szanse na jego złamanie są takie same jak dla każdego skrótu.
Być może poprzednie plakaty uważają, że dane wejściowe są istotne; to nie jest. Tak długo, jak cokolwiek wpiszesz w funkcję skrótu, wygeneruje pożądany skrót, przeprowadzi cię przez, prawidłowe lub nieprawidłowe wejście.
Teraz tęczowe stoły to inna historia. Ponieważ tablica tęczy zawiera tylko surowe hasła, dwukrotne mieszanie może być dobrym środkiem bezpieczeństwa, ponieważ tablica tęczy zawierająca każdy skrót każdego skrótu byłaby zbyt duża.
Oczywiście, rozważam tylko przykład podany przez OP, w którym to hasło jest szyfrowane zwykłym tekstem. Jeśli do skrótu podasz nazwę użytkownika lub sól, będzie to inna historia; dwukrotne haszowanie jest całkowicie niepotrzebne, ponieważ tęczowy stół byłby już zbyt duży, aby był praktyczny i zawierał odpowiedni hasz.
W każdym razie nie jestem tutaj ekspertem od bezpieczeństwa, ale tak właśnie wyciągnąłem wnioski z mojego doświadczenia.
źródło
Z tego, co przeczytałem, może być zalecane ponowne hashowanie hasła setki lub tysiące razy.
Chodzi o to, że jeśli możesz sprawić, że kodowanie hasła zajmie więcej czasu, atakujący musi pracować nad wieloma domysłami, aby złamać hasło. Wydaje się to być zaletą ponownego mieszania - nie dlatego, że jest bardziej kryptograficznie bezpieczny, ale generowanie ataku słownikowego zajmuje więcej czasu.
Oczywiście komputery stają się coraz szybsze, więc ta przewaga zmniejsza się z czasem (lub wymaga zwiększenia iteracji).
źródło
Osobiście nie zawracałbym sobie głowy wieloma hashami, ale upewniłbym się również, że hashame UserName (lub inne pole User ID), a także hasło, aby dwóch użytkowników z tym samym hasłem nie skończyło się tym samym hashem. Prawdopodobnie wrzuciłbym też do łańcucha wejściowego inny stały ciąg znaków, na wszelki wypadek.
źródło
Załóżmy, że używasz algorytmu mieszającego: oblicz rot13, weź pierwsze 10 znaków. Jeśli zrobisz to dwa razy (a nawet 2000 razy), możesz stworzyć funkcję, która jest szybsza, ale daje ten sam wynik (mianowicie wystarczy pobrać pierwsze 10 znaków).
Podobnie może być możliwe utworzenie szybszej funkcji, która daje taki sam wynik, jak powtarzająca się funkcja skrótu. Zatem wybór funkcji skrótu jest bardzo ważny: podobnie jak w przykładzie zgnilca 13 nie jest powiedziane, że powtarzanie skrótu poprawi bezpieczeństwo. Jeśli nie ma badań mówiących, że algorytm jest zaprojektowany do użytku rekurencyjnego, bezpieczniej jest założyć, że nie zapewni on dodatkowej ochrony.
To powiedziawszy: dla wszystkich oprócz najprostszych funkcji haszujących najprawdopodobniej eksperci w dziedzinie kryptografii obliczą szybsze funkcje, więc jeśli chronisz się przed atakującymi, którzy nie mają dostępu do ekspertów w dziedzinie kryptografii, prawdopodobnie bezpieczniej jest w praktyce korzystać z powtarzającej się funkcji haszującej .
źródło
Ogólnie rzecz biorąc, nie zapewnia żadnego dodatkowego bezpieczeństwa podwójnemu hashowi lub podwójnemu szyfrowaniu. Jeśli możesz raz złamać skrót, możesz go ponownie złamać. Zazwyczaj jednak nie szkodzi to bezpieczeństwu.
W twoim przykładzie użycia MD5, jak zapewne wiesz, są pewne problemy z kolizją. „Podwójne mieszanie” tak naprawdę nie chroni przed tym, ponieważ te same kolizje nadal będą skutkowały tym samym pierwszym haszem, który możesz następnie MD5 ponownie uzyskać drugi hasz.
Chroni to przed atakami słownikowymi, takimi jak „odwrotne bazy danych MD5”, ale także solenie.
W stycznej Podwójne szyfrowanie czegoś nie zapewnia żadnego dodatkowego bezpieczeństwa, ponieważ wszystko, co robi, powoduje powstanie innego klucza, który jest kombinacją dwóch faktycznie używanych kluczy. Tak więc wysiłek znalezienia „klucza” nie jest podwojony, ponieważ tak naprawdę nie trzeba szukać dwóch kluczy. Nie jest to prawdą w przypadku mieszania, ponieważ wynik skrótu nie jest zwykle tej samej długości, co oryginalne wejście.
źródło
Podwójne haszowanie ma dla mnie sens tylko wtedy, gdy haszuję hasło na kliencie, a następnie zapisuję skrót (z inną solą) tego skrótu na serwerze.
W ten sposób nawet jeśli ktoś włamał się na serwer (ignorując w ten sposób bezpieczeństwo zapewniane przez SSL), nadal nie może uzyskać dostępu do czystych haseł.
Tak, będzie miał dane wymagane do włamania się do systemu, ale nie byłby w stanie wykorzystać tych danych do naruszenia bezpieczeństwa kont zewnętrznych użytkownika. Ludzie znani są z używania tego samego hasła do praktycznie wszystkiego.
Jedynym sposobem, w jaki mógł dostać się do jasnych haseł, jest zainstalowanie keygen na kliencie - i to już nie jest twój problem.
W skrócie:
źródło
Obawa o zmniejszenie przestrzeni wyszukiwania jest matematycznie poprawna, chociaż przestrzeń wyszukiwania pozostaje na tyle duża, że dla wszystkich praktycznych celów (zakładając, że używasz soli), przy 2 ^ 128. Ponieważ jednak mówimy o hasłach, liczba możliwych 16-znakowych ciągów znaków (alfanumeryczne, wielkie litery, kilka symboli wrzuconych) wynosi około 2 ^ 98, zgodnie z moimi obliczeniami z tyłu koperty. Tak postrzegane zmniejszenie przestrzeni wyszukiwania nie jest tak naprawdę istotne.
Poza tym kryptograficznie nie ma żadnej różnicy.
Chociaż istnieje krypto-prymityw zwany „łańcuchem mieszania” - technika, która pozwala na wykonanie kilku fajnych sztuczek, takich jak ujawnienie klucza sygnatury po jego użyciu, bez poświęcania integralności systemu - przy minimalnej synchronizacji czasu, to pozwala na ominięcie problemu początkowej dystrybucji kluczy. Zasadniczo obliczasz duży zestaw skrótów haszowania - h (h (h (h (h .... (h (k)) ...))), użyj n-tej wartości do podpisania, po ustalonym okresie, wyślij wypisz klucz i podpisz go za pomocą klucza (n-1). Odbiorcy mogą teraz sprawdzić, czy wysłałeś wszystkie poprzednie wiadomości, i nikt nie może sfałszować twojego podpisu, ponieważ upłynął okres, przez który jest on ważny.
Ponowne mieszanie setek tysięcy razy, jak sugeruje Bill, to tylko marnowanie procesora. Użyj dłuższego klucza, jeśli obawiasz się, że ludzie złamią 128 bitów.
źródło
Jak sugeruje kilka odpowiedzi w tym artykule, istnieją przypadki, w których może to poprawić bezpieczeństwo, a inne, w których to zdecydowanie boli. Istnieje lepsze rozwiązanie, które zdecydowanie poprawi bezpieczeństwo. Zamiast podwoić liczbę obliczeń wartości skrótu, podwoić rozmiar soli lub podwoić liczbę bitów użytych w wartości skrótu lub wykonać obie te czynności! Zamiast SHA-245, wskocz na SHA-512.
źródło
Podwójne haszowanie jest brzydkie, ponieważ jest bardziej niż prawdopodobne, że atakujący zbudował stół, aby wymyślić większość skrótów. Lepiej jest solić swoje skróty i mieszać skróty razem. Istnieją również nowe schematy „podpisywania” skrótów (w zasadzie solenia), ale w bardziej bezpieczny sposób.
źródło
Tak.
Absolutnie nie używaj wielu iteracji konwencjonalnej funkcji skrótu, takiej jak
md5(md5(md5(password)))
. W najlepszym razie marginalnie zwiększysz bezpieczeństwo (taki schemat nie zapewnia prawie żadnej ochrony przed atakiem GPU; po prostu potokuj go.) W najgorszym przypadku zmniejszasz przestrzeń mieszania (a tym samym bezpieczeństwo) z każdą dodaną iteracją . Jeśli chodzi o bezpieczeństwo, mądrze jest zakładać najgorsze.Czy użyć hasła, które zostało zaprojektowane przez właściwy szyfrant być skutecznym hash hasła i odporny zarówno brute-force oraz ataki czasowo-przestrzennych. Należą do nich bcrypt, scrypt, aw niektórych sytuacjach PBKDF2. Hash oparty na glibc SHA-256 jest również akceptowalny.
źródło
Wyjdę na kończynę i powiem, że w pewnych okolicznościach jest bezpieczniejsza ... nie głosuj jednak jeszcze!
Z matematycznego / kryptograficznego punktu widzenia jest to mniej bezpieczne, z tego powodu jestem pewien, że ktoś inny da ci jaśniejsze wyjaśnienie niż ja.
Istnieją jednak duże bazy danych skrótów MD5, które częściej zawierają tekst „hasła” niż jego MD5. Podwójne haszowanie zmniejsza więc skuteczność tych baz danych.
Oczywiście, jeśli użyjesz soli, wówczas ta zaleta (wada?) Zniknie.
źródło