Prawdziwą odpowiedzią na twoje pytanie jest po prostu nie przechowuj tam haseł, jeśli nie możesz ich odpowiednio zabezpieczyć.

„System nie obsługuje odpowiednich algorytmów haszowania haseł” nie jest dobrym pretekstem do złamania zabezpieczeń bezpieczeństwo Twoich użytkowników. Albo znajdź sposób na prawidłowe haszowanie haseł za pomocą silnego i odpowiednio skonfigurowanego algorytmu, albo nie przechowuj ich.

Ale udziel bezpośredniej odpowiedzi na swoje pytanie: tak, coś jest lepsze niż nic. SHA-1 lub SHA-2 to zdecydowanie ulepszenie w stosunku do zwykłego tekstu.

Aby odpowiedzieć na pytanie „to gdzie powinny iść hasła?” pytanie - Na podstawie sformułowania zakładam, że istnieje nowa funkcja / żądanie oprogramowania, które wymaga od systemu przechowywania haseł.

Jeśli system nie może prawidłowo i bezpiecznie przechowywać haseł (zgodnie z nowoczesnymi standardami bezpieczeństwa), wówczas (osobiście) odrzucę żądanie. Umyślne praktykowanie słabych zabezpieczeń z powodu istniejących ograniczeń systemu lub w celu złagodzenia biznesowego przypadku użycia jest złą praktyką. Chciałbym poinformować każdego, kto złożył wniosek, że mam dwie realne opcje:

1. Musimy całkowicie przebudować system na taki, który obsługuje współczesne praktyki bezpieczeństwa (takie jak prawidłowe szyfrowanie haseł kryptograficznych).

2. Po prostu nie mogę dodać nowej funkcji / żądania do istniejącego systemu, ponieważ zagroziłoby to bezpieczeństwu.

Tak, słaby hash kryptograficzny jest lepszy niż brak hasha.

Powody haszowania haseł są następujące w przypadku kradzieży bazy danych hasła:

1. Uniemożliwić atakującemu uzyskanie haseł w postaci zwykłego tekstu.
2. Uniemożliwić atakującemu poznanie, którzy użytkownicy mają to samo hasło (uzyskuje się to poprzez nadanie każdemu użytkownikowi unikalnej soli.

1 to wyścig zbrojeń: chcesz użyć większej, wolniejszej funkcji skrótu, tak aby atakujący kosztował więcej energii elektrycznej w celu wykonania łamania skrótu metodą brutalnej siły. Pojedyncza iteracja SHA-1/2 jest lepsza niż brak skrótu, ponieważ atakujący musi trochę złamać. Pojedyncza iteracja solonego SHA-1/2 zmusi go do zrobienia jakiegoś crackowania bez możliwości użycia wstępnie obliczonego tęczowe tabele . Przejście do bardziej wyszukanych skrótów haseł (argon2, bcrypt lub starszego scrypt, pbkdf2) z wyższym współczynnikiem pracy jeszcze bardziej zwiększy koszty elektryczności pęknięcia.

Korzystanie każdy solony cryptog raphic hash (nawet te niezalecane do haseł, jak SHA-1, SHA-2) da korzyści 2.

W swej istocie PBKDF2 jest po prostu iterowanym i solonym SHA-1 / 2, więc poszukałbym w Google implementacji PBKDF2 i zbudowałbym twój wrapper wokół SHA-1/2, który go emuluje (lub lepiej, przejdź całą drogę i faktycznie zaimplementuj PBKDF2).

Jak powiedzieli inni, spróbuj znaleźć silną samodzielną implementację w języku Twojej platformy, jeśli to w ogóle możliwe.

Ale jeśli nie możesz użyć silnego skrótu ... powinieneś zdecydowanie nadal haszuje hasła użytkowników, nawet ze słabym hashem - ponieważ nawet słaby hash chroni silne hasło .

Kiedy narzędzia takie jak hashcat mogą odgadnąć miliardy haseł na sekundę , słabe skróty nie ochronią słabych haseł. Ale jeśli jeden z twoich świadomych bezpieczeństwa użytkowników wybierze niemożliwe do złamania hasło, takie jak `` SDXBZsRVBKVnXznpLTBMIKhTX '' lub `` aerently-imitate-snowmelt-heirdom-leeching '' ... wtedy nawet słaby hash, taki jak SHA1, nadal umieści to hasło poza zasięgiem brutalnej siły atak.

Używając nawet słabego skrótu, możesz przynajmniej umożliwić swoim sprytnym użytkownikom ochronę siebie nawet jeśli twój system jest słaby . (A jeśli masz możliwość rozciągania - aby użyć tego samego algorytmu tysiące razy z rzędu - spowolni to również atakującego).

Ale Twoi doświadczeni użytkownicy nie będzie ponownie używać haseł, więc nawet to ma ograniczoną wartość (z wyjątkiem „częściowo doświadczonych” użytkowników, którzy wybrali hasła wystarczająco silne, aby oprzeć się brutalnej przemocy, ale mogą ponownie używać tego hasła w innym miejscu lub przy użyciu schematu wyboru haseł możliwego do przeanalizowania przez człowieka. .. więc użycie nawet słabego skrótu ochroni również tych użytkowników).

Najlepszą opcją dla wszystkich użytkowników jest znalezienie sposobu na użycie silnego skrótu.

[Edytuj: OP zaktualizował pytanie, aby wskazać, że są jedynym użytkownikiem systemu i może ustawić dowolne losowe hasło (co wydaje mi się dość dziwne; ja nie znam system z tak dziwną kombinacją „Jestem jedynym użytkownikiem”, „Mogę wybrać tylko z kilku algorytmów mieszających” i „Wszystkie algorytmy haszujące są słabe”). Tak czy inaczej, sprawia to, że moje obawy dotyczące ochrony słabych haseł zwykłych użytkowników są nieistotne dla tego konkretnego pytania. Inne odpowiedzi powinny wyjaśniać na początku ich odpowiedzi, że udzielają porad, które normalnie byłyby dość złe i mają zastosowanie tylko do tego bardzo konkretnego pytania.]

[Edycja 2: Zwróć uwagę, że „słaby hasz” to nie to samo, co „zły hash”. Przykładem złego skrótu może być deszyfrowanie (ponieważ obcina hasła do 8 znaków). Więc nawet jeśli twoje hasło jest silne, 8-znakowy hash deszyfrowania może zostać brutalnie wzmocniony w ciągu 10 dni lub mniej na systemie łamania klasy prosumenckiej (6 GPU).]

SHA-2 w tym konkretnym przypadku jest tak samo bezpieczny jak PBKDF / scrypt / bcrypt. Iteracje są niepotrzebne i niepotrzebne. Generuj hasła o dużej entropii (256 bitów) i zapomnij o KDF, a nawet solach.

W rzeczywistości bardziej sensowne jest użycie SHA-2 niż PBKDF, ponieważ nie ma istniejącej implementacji platformy algorytm i „toczenie własnej kryptowaluty” to nie-nie.

To dość mocne stwierdzenie. Istota pytania polega na tym, że OP ma pełną kontrolę nad hasłami, które przechowuje w systemie i wie, że tylko on będzie przechowywał hasła w systemie.

Sygnał wykorzystuje konstrukcję o nazwie HKDF w swoim algorytmie podwójnej zapadki, która zasadniczo stosuje algorytm haszujący tylko dla jednej iteracji.

Dlaczego jest to w porządku?

Hasła KDF istnieją dokładnie z jednego powodu: haseł o niskiej entropii. Większość ludzi nie pamięta w głowach 128- lub 256-bitowego klucza wygenerowanego przez CSRNG. Zaryzykowałbym, że większość ludzi pamięta co najwyżej 40-bitowy losowy ciąg przez wystarczająco długi okres czasu, aby go używać.

Prawie wszystkie funkcje skrótu (nawet MD4, MD5 i SHA-1 ale skoro powiedziałeś, że masz SHA-2 na platformie, bądźmy tutaj bezpieczni) mają funkcję o nazwie odporność na obraz przed obrazem, która jest wystarczająco dobra dla Twojej aplikacji, ponieważ kontrolujesz wszystkie przechowywane hasła w twoim systemie. Oznacza to, że obliczenie jest niewykonalne, biorąc pod uwagę hash, aby wygenerować coś, co jest mieszane z tym samym hashem.

Upraszczając trochę, najbardziej praktycznym sposobem generowania obrazu wstępnego dla jednej z tych funkcji skrótu jest zachowanie próbowanie danych wejściowych. Istnieje kilka przykładów ataków, które działają nieco lepiej niż brutalna siła, ale są całkowicie niewykonalne. Teraz, jeśli hasło / klucz, które wybrałeś do funkcji skrótu, ma tylko 16 bitów entropii, ta właściwość odporności nie zrobi wiele, ponieważ atakujący będzie mógł wypróbować wszystkie 65536 różnych danych wejściowych, które mógłbyś wprowadzić.

Dlaczego kontrola haseł ma znaczenie

Myśl mniej o tym, co wpisujesz, jako o „hasłach”, ale bardziej jak o kluczach kryptograficznych. Dopóki haszujesz klucze, które mają entropię większą lub równą liczbie bitów wyjściowych przez wybór funkcji skrótu (dla SHA-256 jest to 256 bitów), to wszystko jest w porządku, po prostu wykonując jedną iterację skrótu nad nim, aby zapobiec wyjęciu klucza. Odporność haszu na obraz przed obrazem w połączeniu z wysoką entropią klucza oznacza, że ​​osoba atakująca po prostu nie może odgadnąć wartości, jaką włożyłeś. Nie ma potrzeby wykonywania tysięcy iteracji lub kłótni ze stroną biznesową lub rozumowania nad abstrakcyjnym atakiem, aby tego nie robić. -so-wrażliwi szefowie. Opór FPGA / ASIC jest kwestią sporną, gdy musisz odgadnąć 256-bitowe dane wejściowe do funkcji skrótu.

Zalecenia

Wygeneruj swoje „hasła” ze sprzętowym RNG lub CSPRNG i niezwłocznie zniszcz wszelkie materiały wyjściowe, które mogłyby zostać użyte do odzyskania dowolnego stanu wewnętrznego, a tym samym haseł. Upewnij się, że są to 256 bitów. Jeśli twój system nie obsługuje haseł innych niż alfanumeryczne lub ASCII, po wygenerowaniu 256 bitów zakoduj je w base-64 lub base-26 lub binarnie, jeśli chcesz. (Oznacza to, że rzeczywiste hasła, które przesyłasz, będą dłuższe niż 32 bajty, ale to nie pomaga zbytnio w entropii.)

Traktuj te hasła jak klucze kryptograficzne - najlepiej byłoby, gdyby były przechowywane na sprzęcie tokeny. W tym celu bardzo dobrze działa sprzętowy menedżer haseł. Przechowuj skróty SHA-256 w swoim systemie i weryfikuj hasła przez haszowanie i porównywanie. Powinieneś odrzucić wszystkie próby haseł, które nie pasują do twojego kryterium generowania (przykładem może być hasło wybrane przez użytkownika < 256 bitów), nawet jeśli skróty pasują, i nie powinieneś pozwalać nikomu ustawiać hasła, które nie pochodzi z CSRNG. To powinno być udokumentowane. Jeszcze lepiej jest, jeśli dodasz niejasny bajt sumy kontrolnej na końcu generowanych haseł, które są weryfikowane przez platformę, zanim pozwoli ci ustawić hasło. To powinno powstrzymać wszystkich, z wyjątkiem najbardziej przezabawnie niekompetentnych ludzi, od umieszczania na platformie czegoś mniejszego niż klucz kryptograficzny.

Kryptografia klucza publicznego

Twój przypadek użycia to trochę dziwny. Większość miejsc utrzymuje hasła, ponieważ skonfigurowanie PKI i kontakt z użytkownikami końcowymi jest bardzo trudny, szczególnie w przypadku kluczy publicznych. Ponieważ wydaje się, że jesteś jedyną osobą wprowadzającą hasła do systemu, może bardziej sensowne byłoby przechowywanie kluczy publicznych Ed25519 lub ECDSA w systemie i pisanie tam kodu, który implementuje protokół typu wyzwanie-odpowiedź (prosty to podpis 256- wartość bitową - ale uważaj, aby nie używać tych kluczy ponownie, ponieważ ktoś może oszukać Cię do wyrejestrowania Twojego Bitcoina lub zeznania karnego). Urządzenie, które łączyłoby się z twoim systemem tutaj i utrzymywało klucze prywatne, prawdopodobnie ma silną implementację kryptografii klucza publicznego i nie miałoby problemu z uwierzytelnieniem się. Twoja implementacja weryfikacji podpisu typu „roll my own” może być najmniej bezpieczna na świecie pod względem ataków side-channel (pomyśl o umieszczeniu jej całego stanu na billboardzie lub blockchainie), o ile da poprawną odpowiedź, i wszystko byłoby w porządku, ponieważ algorytm weryfikacji po prostu nie ma dostępu do kluczy prywatnych.

Zgadzam się z Mike'iem i Roycem w ich odpowiedziach i nie czuję potrzeby powtarzania tego, co dobrze opisali. Jednak chciałem bardziej bezpośrednio odnieść się do twojego komentarza:

Dodatkowe informacje: Będę jedyną osobą przechowującą hasła w tym systemie, więc mogę 1) zagwarantować, że żadne z haseł nie będzie użyte dwukrotnie i 2) upewnij się, że hasła będą miały bardzo wysoką entropię.

Ta informacja jest zarówno ważna, jak i nieistotna. Oto dlaczego:

Przypadek haszowania haseł

Zawsze ważne jest, aby pamiętać dlaczego haszujemy hasła, a wszystko się kończy aż do ponownego użycia hasła. Powodem, dla którego haszowanie haseł jest tak ważne, jest to, że kiedy Twój system zostanie naruszony i hasła zostaną skradzione, nie tylko dostęp do Twojej witryny jest zagrożony, ale dostęp do każdej witryny, w której użytkownicy ponownie używali tego samego adresu e-mail / hasła połączenie, które (jak wiemy) często się zdarza. Haszowanie haseł polega na ochronie użytkowników przed sobą. Gdyby absolutnie wszyscy używali silnych i unikalnych haseł w każdej witrynie, haszowanie haseł byłoby znacznie mniej potrzebne. Nadal miałby pewną wartość, ponieważ istnieją przypadki użycia, w których haker może uzyskać dostęp tylko do odczytu do zrzutu bazy danych, więc zaszyfrowane hasła mogą zapewnić pewną ochronę przed uzyskaniem przez atakujących rzeczywistego dostępu do systemu. Jednak jeśli ludzie używają silnych i unikalnych haseł wszędzie, więc haszowanie haseł stałoby się bardziej drugorzędnym problemem, a nie absolutnie krytyczną koniecznością, jaką jest dzisiaj.

Jeśli więc możesz zagwarantować, że każdy użytkownik twojego systemu będzie używał tylko silnych i unikalnych haseł (tj. hasła, które nie były używane w innych witrynach), to myślę, że nawet coś tak prostego jak SHA2 byłoby w rzeczywistości całkowicie rozsądnym wyborem, niezależnie od tego, czy dostępne były lepsze funkcje.

ALE: zmieniające się potrzeby biznesowe

Zachęcam Cię jednak do dokładnego sprawdzenia swoich założeń (że silne unikalne hasła będą jedynymi, jakie kiedykolwiek pojawią się w Twoim systemie). W przeszłości widziałem, jak potrzeby biznesowe często się zmieniają, aby polegać na takich założeniach w krytycznych obszarach biznesowych (co może nie być - oczywiście nie wiem, co to oznacza). Problem w tym, że biznes potrzebuje zmian. Może to tylko ja, ale z mojego doświadczenia wynika, że ​​rzeczy, które miały być tymczasowe lub ograniczone tylko do kilku osób, nieuchronnie zamieniają się w krytyczne aplikacje biznesowe używane przez wszystkich w firmie i nagle masz słaby schemat haseł chroniący krytyczny biznes infrastruktura. Nie zawsze tak się stanie, ponieważ ludzie próbują iść na skróty, ale ponieważ 12 miesięcy później zapominasz, że nie użyłeś dobrego skrótu hasła lub odchodzisz, a następny facet nie robi nie przyjrzyj się temu, albo jesteś pod presją, aby dotrzymać terminu i zapomnisz, lub, lub, lub ...

Z mojego doświadczenia wynika, że ​​firmy mają naruszenia bezpieczeństwa nie dlatego, że bezpieczeństwo jest trudne , ale dlatego, że nie rozumieją potrzeby spędzania czasu (zwanego też pieniędzmi) na dobrych praktykach bezpieczeństwa i chodzą na skróty tam, gdzie nie powinni. Jasne, właśnie teraz świetny schemat haszowania haseł nie ma znaczenia, ale czy naprawdę możesz zagwarantować, że to się nie zmieni w przyszłości? Jeśli nie masz teraz czasu na poprawne haszowanie hasła, czy możesz zagwarantować, że gdy zmienią się potrzeby i nagle stanie się to ważne, będziesz miał na to czas od razu?

Oczywiście pod koniec dnia każda firma musi zarabiać pieniądze, a czasami „Utrzymajmy to na razie w prosty sposób, aby wyjść na zewnątrz” jest całkowicie rozsądną odpowiedzią. Bądź jednak ostrożny, ponieważ zbyt częste podejmowanie tej decyzji powoduje, że firmy mają systemy wypełnione lukami w zabezpieczeniach. Jako firma musisz znaleźć dla siebie tę równowagę. Problem polega na tym, że gdy firmy stale oszczędzają na bezpieczeństwie, ostatecznie najbardziej szkodzą ich klienci.

Muszę przechowywać hasła w systemie, który nie oferuje żadnego z algorytmów zalecanych do haszowania haseł (np. bcrypt, scrypt lub PBKDF2). Czy lepiej byłoby użyć nieodpowiedniego algorytmu (np. Rodziny SHA-1 lub SHA-2), zanim nie użyjesz żadnego?

Ścisła odpowiedź na twoje pytanie brzmi: tak. Powodem jest to, że szybkie skróty nie chronią słabych haseł, ale będą chronić bardzo silne hasła, a to jest zdecydowanie lepsze niż zwykły tekst.

Jednakże, jeśli masz SHA-1 lub SHA-2, są to bardzo nieliczne (jeśli w ogóle!) wymówki, aby nie używać PBKDF2. Tak, powszechną radą jest „nie rzucaj własnej kryptowaluty”, ale jeśli masz SHA-1 lub SHA-2, który jest już podstawowym elementem składowym PBKDF2, a w przypadku haszowania hasła zapisywanie własna implementacja PBKDF2 nie może być gorsza niż nie . Oto odpowiedni dokument RFC i sekcja:

• https://tools.ietf.org/html/rfc2898#section-5.2

Kiedy mówią "funkcja pseudolosowa", powinieneś użyć jakiegoś wariantu HMAC (najlepiej HMAC-SHA-512, ale każdy z nich wystarczy). Twoja biblioteka prawdopodobnie ma już implementacje HMAC, ale jeśli tak nie jest, haszowanie haseł jest ponownie przypadkiem, w którym implementacja własnej nie może być gorsza.

Odpowiadając na pytanie: tak, użyj najlepszego algorytmu, do którego masz dostęp. Jeśli masz kilka, możesz je połączyć (uwaga: konkatenacja haseł, np. Sha1 (hasło) + suma md5 (hasło), jest bardziej podatna na zgadywanie, ponieważ atakujący może wybrać, który hash chce odgadnąć, ale kolizje są znacznie mniejsze prawdopodobnie, ponieważ oba hasła muszą się zgadzać. Używaj losowych, różnych soli dla każdego hasła.

Mówisz, że Twój system „nie oferuje żadnego z algorytmów zalecanych do haszowania haseł”. Zachęcamy do ponownego przeanalizowania tego założenia.

Prawie każdy współczesny język programowania ma implementacje bezpiecznych skrótów. Nie jest konieczne, aby było to zaimplementowane w gotowej, wstępnie zainstalowanej bibliotece - na przykład jeśli twój program jest napisany w C, powinieneś być w stanie znaleźć implementacje dowolnego skrótu w C. Jako samodzielna funkcja. Nawet małe procesory, takie jak Arduino, mają bcrypt i PBKDF2, dostępne z półki. Dodatkowy nakład pracy jest minimalny. mógłby nawet zaimplementować go samodzielnie (ale bądź bardzo ostrożny i bardzo dokładnie przetestuj!).

Nie wątpię, że są wyjątki, ale nie ma ich wiele.

TAK, nawet hash niskiej jakości jest znacznie lepszy niż przechowywanie haseł w postaci zwykłego tekstu

Jeśli rozumiem, że aktualizujesz, ktoś inny będzie przeprowadzał uwierzytelnianie (niezwiązane z Ty i Twoja baza danych), a baza danych skrótów haseł będzie używana tylko do wykrywania duplikatów haseł? Wymóg określenia entropii hasła byłby oparty na tekście jawnym i nie ma związku z przechowywaniem skrótów haseł, prawda?

Wtedy możesz przechowywać w swojej bazie danych skrótów tylko niewielką część obliczonego sha2 hash salt + zwykły tekst (na przykład przechowywanie tylko małych 8 bajtów z 32 bajtów zwróconych przez sha256), co wystarczy do wykrycia duplikatów z brak fałszywych alarmów w prawdziwym życiu, ale wciąż niewystarczające, aby umożliwić atakującemu użycie tęczowych tabel do odgadnięcia oryginalnego hasła w przypadku kradzieży bazy danych.

(Uwaga: jeśli WYKORZYSTUJESZ uwierzytelnianie, a nie tylko wykrywasz zduplikowane hasła, to usunięcie części hasha byłoby oczywiście okropnym pomysłem!)

Tak , użycie słabego skrótu jest lepsze niż żadne.

Myślę, że należy również wziąć pod uwagę sposób administracyjny. Jeśli utrzymujesz bazę danych (ale nie możesz zmieniać jej struktury, kto wie dlaczego ...) nie powinieneś widzieć haseł w postaci zwykłego tekstu, nawet jeśli jesteś osobą o największej liczbie całkowitej i nie zaszkodziłbyś tym informacjom. Podobnie jak przysłowie: okazja czyni złodzieja.

Tak, zdecydowanie lepiej jest użyć prostego skrótu niż żadnego (chociaż widząc, jak najwyraźniej implementujesz system, nie widzę, co przeszkadza Ci w prawidłowym wykonywaniu zadań).

Jednak biorąc pod uwagę twoją edycję "Dodatkowe informacje", można by powiedzieć, że nie potrzebujesz nawet soli! Nie oznacza to, że jest to dobry projekt i nie polecałbym tego, ale jeśli poważnie myślisz o swoich gwarancjach, wystarczy prosty, bezpieczny skrót o rozsądnej wielkości, ściśle mówiąc.

Dlaczego takie zamieszanie związane z przechowywaniem haseł w pierwszej kolejności? Zwykle hasła mają niską entropię, a nawet po zaszyfrowaniu istnieje spora szansa na odgadnięcie hasła, nawet bardziej, ponieważ funkcje skrótu są bardzo szybkie , trywialnie równoległe i istnieją tęczowe tablice, które zapewniają tani skrót . Zatem nawet brak możliwości odczytania hasła po zaszyfrowaniu niekoniecznie oznacza, że ​​hasła są nieodwracalne.
W zasadzie, biorąc pod uwagę nieskończony czas, można odzyskać każde hasło w każdym systemie (lub przynajmniej hasło, które będzie działać). To tylko konsekwencja faktu, że istnieje skończona liczba wyników funkcji skrótu. Tak więc w quasi-wyczerpującym wyszukiwaniu jakaś sekwencja wejściowa musi koniecznie generować działające wyjście.
Na szczęście napastnicy nie mają nieskończonego czasu, więc naszym zadaniem jest upewnić się, że nie mają rozsądną szansę na znalezienie sekwencji wejściowej, która działa w ograniczonym czasie i przy ograniczonych zasobach energii.

Teraz ... mówisz, że jesteś jedynym użytkownikiem i możesz zagwarantować że hasła są losowe i mają wysoką entropię. To wyklucza większość obaw związanych ze zgadywaniem.

Biorąc pod uwagę „rozsądny” rozmiar skrótu, oznacza to, że szansa znalezienia haszyszu w tablicy tęczowej jest minimalna (zero, mniej więcej), a szansa na znalezienie go przez brutalną siłę jest równie mniej więcej zerowa. Nie ma mowy, żeby ktoś złamał brutalną siłę SHA-256, nie mówiąc już o SHA-512. Ta idea po prostu nie jest zgodna z naszym zrozumieniem, jak działa fizyka.
Jeśli skrót jest wystarczająco duży, a hasła mają gwarancję (jak twierdzisz), że będą niepowtarzalne, losowe, o dużej entropii ... po prostu dobrze jest raz przejść z haszowaniem.

Oczywiście normalnie system powinien działać niezawodnie, nawet jeśli nie możesz zapewnić tej gwarancji (lub żadnej gwarancji z tego powodu). Dlatego nie jest to najlepszy projekt.

Tak, powinno być dobrze. SHA1 i 2 są nadal dość mocne do przechowywania skrótów haseł o dużej entropii i zapewniają odpowiednią ochronę przed brutalnym wymuszeniem. SHA2 zapewnia lepszą ochronę niż SHA1. Luki w SHA2 nie są istotne dla tego scenariusza, ponieważ dotyczą tworzenia kolizji, w których początkowy tekst jawny jest już znany.

Aby zgodzić się z powyższymi doskonałymi odpowiedziami, chcę udzielić pochlebnej, ale przeciwnej odpowiedzi:

Nie . Używanie słabego skrótu jest gorsze niż jego całkowity brak.

Słaby hash daje złudzenie bezpieczeństwa.

Podczas gdy Ty i Twoi menedżerowie może obecnie zrozumieć, że hash nie zapewnia prawdziwego bezpieczeństwa, menedżer lub programista może pomyśleć, że hash jest bezpieczny. Osoby te mogą zdecydować się na przechowywanie dodatkowych informacji przy użyciu danego skrótu.

Istnieje również ryzyko, że kierownictwo może po prostu nie zrozumieć, że hasz nie jest bezpieczny. W przypadku podjęcia decyzji o zainwestowaniu w rozwój zabezpieczeń mogą zdecydować, że „obecny system jest wystarczająco dobry”, ponieważ został już zahaszowany, a haszowanie jest uważane za najlepszą praktykę.