Pytanie:
Czy lepiej jest użyć nieodpowiedniego algorytmu haszującego zamiast żadnego?
JFB
2018-11-19 21:16:42 UTC
view on stackexchange narkive permalink

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?


Dodatkowe informacje : będę jedyny przechowywanie haseł w tym systemie, więc mogę 1) zagwarantować, że żadne z haseł nie zostanie użyte dwukrotnie i 2) zapewnić, że hasła będą miały bardzo wysoką entropię.

Więc generujesz hasła i zarządzasz nimi?To nie są hasła użytkowników?Czy mechanizm uwierzytelniania już istnieje, czy jest to nowa funkcja?
Czy masz możliwość * rozciągnięcia * algorytmu - wielokrotnego stosowania tego samego algorytmu?Jeśli tak, zrób to przynajmniej.
Wygląda na to, że masz wysoki stopień kontroli nad przechowywanymi hasłami. Czy nie masz podobnego poziomu kontroli nad * sposobem * ich przechowywania?Czy nie możesz znaleźć czegoś lepszego?
Jestem zmieszany.Jeśli dodajesz kod uwierzytelniający, jak nie możesz pobrać biblioteki, która implementuje nowsze protokoły haszowania?Zastanawiam się również, czy robisz coś takiego, jak dodanie użytkownika administratora do urządzenia, które następnie rozprowadzasz?Myślę, że na to pytanie brakuje wystarczająco dużo szczegółów, aby naprawdę można było na nie odpowiedzieć.Podaj więcej szczegółów na temat tego, co wdrażasz, co będzie zawierać hasło (interfejs sieciowy, urządzenie IoT, cokolwiek) i dlaczego musisz cokolwiek blokować.(Jeśli dystrybuujesz urządzenie, nie ma sensu nawet mieć hasła).
Nie, to fałszywe poczucie bezpieczeństwa, co jest jeszcze gorsze, na szczęście istnieją usługi szyfrowania, z którymi można się połączyć, oto jedna: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
Jeśli naprawdę nie możesz użyć żadnego z algorytmów, których powinieneś użyć (bcrypt, scrypt, i in.), Użyj przynajmniej soli i rozciągania klucza z dużą liczbą (dziesiątek tysięcy) iteracji.Ale poważnie, powinieneś znaleźć sposób na użycie odpowiedniego algorytmu.SHA-1 został teoretycznie uszkodzony z powodu niewielkiej szansy na kolizję.Prawdopodobnie nie jest uszkodzony w praktyce, ponieważ kolizje są niezwykle mało prawdopodobne.Niemniej jednak, jeśli zamierzasz zrobić coś takiego, użyj zamiast tego SHA-256 lub SHA-512.
@RandomUs1r Możesz korzystać z takich usług szyfrowania online tylko wtedy, gdy masz gwarancję, że Twój system będzie online za każdym razem, gdy zostanie użyty.Nie zostało to określone, ale nie można tego zagwarantować.
Rozważ użycie lekkiego kontenera Docker, aby zainstalować wszystkie niezbędne biblioteki, a następnie użyj kontenera do skrótu.
Dlaczego wspominasz, że PW są wyjątkowe?To w ogóle nie powinno mieć znaczenia.
Ponadto zapewnienie niepowtarzalności hasła jest raczej luką niż zabezpieczeniem (jeśli w ogóle): będziesz musiał wskazać użytkownikowi próbującemu ponownie użyć istniejącego hasła, że nie można go użyć, a tym samym wskazać, że to hasło istniejew twojej bazie danych (a przynajmniej taki wniosek jest łatwy)
Projektujemy oprogramowanie tak, aby spełniało określone ograniczenia.Masz dwa konkurujące ze sobą ograniczenia: bezpieczeństwo użytkowników i środowisko technologiczne, które nie może haszować haseł.Rozwiązanie: zmień swoje ograniczenia.Co cenisz bardziej, dbanie o bezpieczeństwo haseł użytkowników czy trzymanie się określonej technologii?
„Dodatkowe informacje” rodzą więcej pytań.Przechowywanie haszów nie "zapewnia, że hasła mają wysoką entropię", a jeśli twój system zabrania różnym użytkownikom posiadania tego samego hasła ("żadne z haseł nie będzie używane dwukrotnie"), to jest to okropny pomysł.Dałeś napastnikowi wyrocznię, która może powiedzieć mu, czy hasło jest już używane w systemie.Nie rób tego!
Ujmując mój powyższy komentarz w inny sposób: nie określiłeś swojego modelu zagrożenia.Ocena środka bezpieczeństwa bez zrozumienia, przed jakim zagrożeniem ma się bronić, jest gdzieś pomiędzy niezwykle trudnym a niemożliwym.Twoje dane tak naprawdę nie pokrywają się z żadnymi standardowymi przypadkami, kiedy w ogóle potrzebujesz kont, abyśmy mogli w oparciu o wiedzę przewidzieć zagrożenia, o których myślisz.W rezultacie otrzymujesz odpowiedzi z założenia, że typowy „użytkownik końcowy tworzy konto i ma pewne zasoby, które wymagają ochrony”.
@LaurentS.Jeśli hasła nie można użyć, poznanie go nie jest ryzykowne.Zapewne wiedząc, że to trochę zmniejsza przestrzeń ataku, ale ponieważ musiałeś już włożyć trochę pracy, aby to określić, atakujący nie wydaje się mieć żadnego zysku netto.
@LaurentS: nie tylko dałeś napastnikowi wyrocznię, ale także zapewniając niepowtarzalność hasła, co w istocie mówi atakującemu, że nie przechowujesz hasła poprawnie.Przy prawidłowym zaszyfrowaniu hasła nie powinno być możliwości stwierdzenia, czy dwa konta używają tego samego hasła.To prawie jak zaproszenie do dalszych badań.
@LieRyan: rzeczywiście.Prawdopodobnie jest to powód, dla którego tak naprawdę nigdy nie spotkałem się z taką funkcją wśród wielu błędów, które do tej pory widziałem.
Czy lepiej zamknąć drzwi swojego domu taśmą klejącą, zamiast zostawiać je otwarte, gdy wychodzisz (jeśli nie masz zamka)?
Dwanaście odpowiedzi:
dFrancisco
2018-11-19 21:22:01 UTC
view on stackexchange narkive permalink

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.

Zaktualizowałem moje pytanie dodatkowymi informacjami. Czy to pomogło?
@JFB Nie przesadnie.Dodatkowe informacje są dobre i oznaczają, że szkody wyrządzone przez złamanie słabo zaszyfrowanych, silnych, nigdy ponownie używanych haseł są oczywiście mniej szkodliwe niż narażanie prawdziwych haseł zwykłych użytkowników, ale nie pomagają zbytnio skupić się na mojej odpowiedzi.
Co się stanie, jeśli mój szef chce, aby system faktycznie przypominał, a nie tylko resetował hasła?Chcą tego tak bardzo, że są gotowi poświęcić za to bezpieczeństwo.Jak odpowiedziałbyś na taką prośbę?
@Gherman, tak jak w przypadku wszystkiego, przeprowadzasz analizę kosztów i korzyści i pozwalasz decydentowi i właścicielowi ryzyka zdecydować.
@dFrancisco odmowa dodania nowej funkcji jest w porządku, jeśli jesteś właścicielem systemu, ale nie masz podstaw do odmowy, jeśli jesteś administratorem lub programistą.*** Doradzaj i edukuj *** to Twoja rola jako specjalisty ds. Bezpieczeństwa.
Lepiej byłoby przeformułować swoją odmowę w * terminach biznesowych *, a nie tylko niejasnym „zabezpieczeniem”.Np. „Świadomie będziemy przechowywać poufne dane w sposób, który ułatwi atakującemu ich uzyskanie.łamanie kłopotów i naraża nas na konsekwencje prawne ”.Ale to * jest * właściwy sposób postępowania w przypadku ogólnego zarządzania użytkownikami.
@Wildcard nie dajmy się zwieść skokom logiki, „śliskim zboczom” i absurdowi reklamowemu.Istnieje szerokie pole do rozegrania między „brakiem odmowy” a „należy dodać funkcję”.Prosimy o dalsze komentarze na czacie.
Podczas gdy słaby hash jest nieco lepszy niż nic, * solony * słaby hash jest znacznie lepszy niż nic.Nic w pytaniu ani w tej odpowiedzi nie odnosi się do solenia, więc prawdopodobnie warto o tym wspomnieć.
„coś jest lepsze niż nic” jest prawdziwe tylko wtedy, gdy coś jest LEPSZE niż nic (i nie daje do zrozumienia, że jest bardziej skuteczne) - na przykład niesolona MD5 lub ROT13 lub cokolwiek innego.
@Joe Dam ci ROT13, ale niesolona MD5 * jest * lepsza niż nic, a solona MD5 jest dramatycznie lepsza niż niesolona SHA3.
@MartinBonner Jeśli w ogóle jest lepszy, to jest tak trywialnie „lepszy”, że możemy (i powinniśmy, aby uniknąć wprowadzania w błąd) zaniedbać różnicę.
Mike Ounsworth
2018-11-19 21:28:28 UTC
view on stackexchange narkive permalink

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).

Sugerowałbym włączenie Argon2 do listy, ponieważ jest to obecnie preferowany algorytm, gdy w modelu zagrożenia znajdują się układy GPU lub łamanie FPGA / ASIC (a powinny).
+1.Zwróć uwagę, że to w rzeczywistości zależy od tego, jak długo twoja baza użytkowników jest gotowa czekać na autoryzację (i jak duże obciążenie może trwać równolegle systemy autoryzacji).Na poziomie poniżej 100 ms bcrypt jest w rzeczywistości bardziej odporny na brutalność.Dopiero powyżej ~ 1s / auth Argon2 staje się lepszy.Referencje: https://twitter.com/Sc00bzT/status/1063895918246862848, https://twitter.com/Sc00bzT/status/1041875128311840768
Czy to naprawdę?Mówisz mi, że bezpiecznie przechowujesz moje dane, daję ci wrażliwe dane do przechowywania, a następnie tracisz dane, ponieważ w rzeczywistości nie są one bezpieczne, czyż nie byłoby lepiej być z przodu i stwierdzić, że nie przechowujesz danych bezpiecznie wpierwsze miejsce?... mówiąc idealistycznie
SHA-1 nie jest jeszcze naruszona przed preimage.To wytrzyma.
@RandomUs1r Co masz na myśli, mówiąc „niezabezpieczone przechowywanie danych”?PBKDF2, choć nieco stary, jest nadal uważany za bezpieczny, jeśli używasz 10000 iteracji SHA-1 lub SHA-2 i unikalnych soli na użytkownika.Jeśli masz dostępny prymityw SHA-2, możesz zbudować PBKDF2 (lub coś, co jest funkcjonalnie równoważne).Proszę poprzeć swoje stwierdzenie, że to tylko iluzja bezpieczeństwa.
„Korzystanie z dowolnego kryptograficznego skrótu daje korzyści 2”.Przypuszczam, że powinno to być oczywiste, ale warto dodać „solony” po „dowolnym”.
Nie znam szczegółów implementacji PBKDF2.Ale zakładając, że masz solidną implementację podstawowego algorytmu haszującego, takiego jak SHA-1 lub SHA-2, czy dopuszczalne jest samodzielne wdrożenie PBKDF2, jeśli programiści nie są ekspertami w dziedzinie kryptografii?
@JFB Myślę, że tak, ale nie dałbym tego nowemu pracownikowi.Spojrzenie na specyfikację PBKDF2 lub implementację open source i zwrócenie uwagi na szczegóły wystarczyłoby.Innymi słowy: ufałbym sobie, że zaimplementuję coś podobnego do PBKDF2 w dzień lub dwa i wykorzystam to w prod.W żadnym wypadku nie ufałbym sobie, że zaimplementuję SHA-2 w mniej niż miesiąc.
Royce Williams
2018-11-19 21:45:45 UTC
view on stackexchange narkive permalink

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).]

Zaktualizowałem moje pytanie dodatkowymi informacjami dotyczącymi przynajmniej możliwości ochrony silnych, niepowtarzalnych haseł
* Ponowne użycie hasła * ma miejsce, gdy użytkownicy zdecydują się używać tego samego hasła w wielu witrynach (Facebook, ich bank itp.) ... a nie wtedy, gdy dwóch użytkowników używa tego samego hasła w * tej samej * witrynie.
Zgadzam się, ale z dodatkowym zastrzeżeniem, że NIE należy używać SHA-1 do tworzenia podsumowania jakichkolwiek poufnych danych (takich jak hasła) bez użycia losowej soli do ponownego wykorzystania hasła, a także rozciągania klucza.
Głosuj za `` nawet słaby hash chroni silne hasło ''
John Adams
2018-11-20 10:27:03 UTC
view on stackexchange narkive permalink

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.

Ja ... hm ... Większość tej odpowiedzi wydaje się być około ** całkowicie ** niepowiązanymi tematami kryptografii i / lub wysoce błędna.Pozostała część jest niezależna od tego, jak faktycznie działają techniki przechowywania haseł.Salting i iteracje to w 100% sposób bezpiecznego przechowywania haseł.Ponadto zalecanie komuś prostego SHA-2 jest * bardzo * złą radą;moja platforma 6x 1080 może odgadnąć 18,7 * miliarda haseł na sekundę * SHA-2, ale tylko 95000 na sekundę bcrypt kosztuje 5 (a bcrypt kosztuje 12 lub więcej to aktualny cel)
@RoyceWilliams Nie jestem specjalistą od bezpieczeństwa, ale jeśli dobrze rozumiem OP, zalecają, aby użytkownicy wprowadzali nie mniej niż 256 bitów entropii dla haseł.Nawet przy twoich 18,7 miliardach prób na sekundę, jeśli matematyka mojej tylnej części serwetki jest poprawna (`(2 ^ 256) / 18.700.000.000 / 60/60/24 / 365`), nadal potrzebujesz 1,963 * e + 59lat na wypróbowanie wszystkich kombinacji, które moim zdaniem kwalifikowałyby się jako „niewykonalne obliczeniowo”, nawet jeśli założyć, że wysoce zoptymalizowany sprzęt byłby 100 000 razy bardziej wydajny.
Innymi słowy, dla nieprofesjonalnego specjalisty od bezpieczeństwa, takiego jak ja, mogłoby się wydawać, że odpowiadający ma rację, ponieważ każdy algorytm haszowania odporny na preimage może być uważany za bezpieczny, jeśli można zagwarantować, że nie zostanie ponownie użyte 256-bitowe hasło entropii.
@RoyceWilliams tak, myślę, że głównym problemem jest to, że ogólna sugestia, którą wysuwa JohnAdams, może być nieco bardziej jasna.Wygląda na to, że sugeruje, aby w ogóle nie używać haseł, ale raczej używać uwierzytelniania opartego na kluczach.W takim przypadku rzeczywiście ani iteracje, ani materia soląca.
Mówiąc prościej, bardzo długie, bezpiecznie wygenerowane hasła są zasadniczo tym, czym są klucze kryptograficzne.
@RoyceWilliams Wydaje się, że źle zrozumiałeś istotę odpowiedzi.Jeśli twoje hasła mają wystarczającą entropię, to KDF jest niepotrzebny.KDF są używane, ponieważ większość haseł ma niską entropię.Kiedy twoje hasła osiągają poziomy entropii porównywalne z kluczami kryptograficznymi, tak naprawdę nie ma znaczenia, jak są zaszyfrowane, o ile hash ma odporność na obraz.
Wszystko to brzmi świetnie ... * jeśli * masz niezwykle rzadki luksus zmuszania wszystkich użytkowników do używania tylko automatycznie generowanych haseł.Gdy tylko użytkownicy będą mogli wybierać własne hasła, wszystkie powyższe argumenty nie mają znaczenia.A zrobienie ogólnego ogólnego stwierdzenia, że szybki hash jest tak samo dobry, jak powolny hash, wysyła dokładnie odwrotny komunikat od tego, co powinni wiedzieć administratorzy systemów i programiści: że * silne skróty chronią słabe hasła, a większość użytkowników wybiera słabe hasła *.
Zwróć również uwagę, że udzieliłem odpowiedzi, zanim OP powiedział nam, że jest jedynym użytkownikiem systemu.Odpowiednio zaktualizowałem moje pytanie i sugeruję, aby wszystkie inne odpowiedzi zostały zredagowane, aby było * bardzo * jasne z góry, dlaczego jest to niezwykły przypadek narożny - w przeciwnym razie udzielają porad, które są * bardzo * złe dla 99,9%przypadków ... i wielu użytkowników SE przejrzy to pytanie, przejdzie do najważniejszych odpowiedzi i dojdzie do dokładnie odwrotnego wniosku niż ten, którego prawie wszyscy potrzebują.
Mój problem z tą odpowiedzią polega na tym, że można ją w zasadzie podsumować w dwóch zdaniach: „Nie używaj haseł, używaj kluczy. Klucze nie mogą być brutalnie forsowane, więc jeśli używasz kluczy, nie musisz się tak bardzo martwić o haszowanie."Jest to z pewnością dobra rada dotycząca bezpieczeństwa i jest w 100% prawdziwa (klucze są znacznie bezpieczniejsze i nie można ich brutalnie wymusić).Jest to jednak mało prawdopodobne, aby była to pomocna rada dla OP, ponieważ konfigurowanie logowania za pomocą kluczy również zajmuje trochę czasu w sposób wygodny dla użytkownika.
Krótko mówiąc, OP stara się zapewnić podstawowe zabezpieczenia przy minimalnym problemie, a Ty proponujesz odpowiedź, która zapewnia niesamowite bezpieczeństwo przy dużej liczbie problemów.Często występuje kompromis między użytecznością a bezpieczeństwem.OP wyraźnie stara się faworyzować stronę użyteczności tego spektrum, a ty proponujesz rozwiązanie, które zapewnia wysokie bezpieczeństwo kosztem zmniejszonej użyteczności.Mówiąc najprościej: jeśli nie ma czasu na ustawienie odpowiedniego algorytmu haszującego, wątpię, czy ma czas na znalezienie sprzętowego RNG.
Conor Mancone
2018-11-19 23:49:13 UTC
view on stackexchange narkive permalink

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.

+1 za „rzeczy, które miały być tymczasowe lub ograniczone do kilku osób, nieuchronnie zamieniają się w krytyczne aplikacje biznesowe”
Luis Casillas
2018-11-20 07:15:06 UTC
view on stackexchange narkive permalink

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:

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.

AMADANON Inc.
2018-11-20 03:25:05 UTC
view on stackexchange narkive permalink

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.

Matija Nalis
2018-11-20 03:07:26 UTC
view on stackexchange narkive permalink

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!)

Lithilion
2018-11-20 14:19:29 UTC
view on stackexchange narkive permalink

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.

Damon
2018-11-20 15:05:32 UTC
view on stackexchange narkive permalink

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.

Jake
2018-11-21 01:49:36 UTC
view on stackexchange narkive permalink

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.

To jest po prostu złe.https://www.pcworld.com/article/3173791/security/stop-using-sha1-it-s-now-completely-unsafe.html https://dusted.codes/sha-256-is-not-a-secure-password-hashing-algorithm
Również ... https://crypto.stackexchange.com/a/35642
Prawda.Artykuł w PC-World mówi o generowaniu kolizji ze znanego tekstu jawnego.To zła wiadomość w przypadku niektórych typów certyfikatów lub integralności plików, ale jest dobra w przypadku haseł.Drugi mówi tylko, że słabe, niesolone hasła są łatwe do złamania.Dotyczy to wszystkich algorytmów haszujących i nie ma znaczenia w tym scenariuszu.Link do SE mówi to samo, co ja.Po prostu upewnij się, że reszta systemu została poprawnie zaimplementowana i użyj silnych haseł.
Gregory Currie
2018-11-23 09:20:32 UTC
view on stackexchange narkive permalink

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ę.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...