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.