Czy BCrypt jest dobrym algorytmem hashującym do użycia w C#? Gdzie mogę go znaleźć? [zamknięte]

Czytałem, że podczas haszowania hasła wielu programistów zaleca używanie algorytmu BCrypt.

Programuję w C# i zastanawiam się czy ktoś zna dobrą implementację dla BCrypt? Znalazłem tę stronę , ale naprawdę Nie wiem, czy jest fałszywa, czy nie.

O czym należy pamiętać wybierając schemat haszowania haseł? Czy BCrypt jest 'dobrą' implementacją?

Author: Svish, 2009-01-26
Source

2 answers

Po pierwsze, niektóre terminy, które są ważne:

Hashing - czynność polegająca na pobraniu ciągu znaków i wytworzeniu sekwencji znaków, których nie można przywrócić do oryginalnego ciągu znaków.

Szyfrowanie symetryczne - (zazwyczaj określane jako "szyfrowanie") - czynność polegająca na pobraniu ciągu znaków i wytworzeniu sekwencji znaków, które można odszyfrować do oryginalnego ciągu za pomocą tego samego klucza szyfrującego, który go zaszyfrował.

Tęcza Tabela - tabela wyszukiwania, która zawiera wszystkie odmiany znaków hashowanych w określonym algorytmie haszującym.

Sól - znany losowy ciąg znaków dołączany do oryginalnego ciągu przed jego zaszyfrowaniem.

Dla. NET Framework, Bcrypt nie posiada jeszcze zweryfikowanej implementacji referencyjnej. Jest to ważne, ponieważ nie ma sposobu, aby dowiedzieć się, czy istnieją poważne wady w istniejącej implementacji. Możesz uzyskać implementację BCrypt dla. NET tutaj . Nie znam się na kryptografii na tyle, by stwierdzić, czy jest to dobra czy zła implementacja. Kryptografia to bardzo głęboka dziedzina. nie próbuj budować własnego algorytmu szyfrowania . Poważnie.

Jeśli zamierzasz wdrożyć własne zabezpieczenie hasłem( sigh), musisz zrobić kilka rzeczy:

  1. użyj względnie bezpiecznego algorytmu hashowego .
  2. Solij każde hasło zanim zostanie zahaszowane.
  3. użyj unikalnej i długiej soli do każde hasło i przechowywać sól z hasłem.
  4. Wymagaj silnych haseł .

Niestety, nawet jeśli to wszystko zrobisz, zdeterminowany haker nadal może potencjalnie rozgryźć hasła, zajęłoby mu to naprawdę dużo czasu. To twój główny wróg: Czas .

Algorytm bcrypt działa, ponieważ zajmuje pięć rzędów wielkości dłużej, aby hashować hasło niż MD5 ; (i nadal znacznie dłużej niż AES lub SHA-512). Zmusza to hakera do poświęcenia dużo więcej czasu na stworzenie tęczowej tabeli w celu wyszukania haseł, co znacznie zmniejsza prawdopodobieństwo, że Twoje hasła będą zagrożone zhakowaniem.

Jeśli używasz soli i hashujesz swoje hasła, a każda sól jest inna, to potencjalny haker musiałby stworzyć tęczową tabelę dla każdej odmiany salt , tylko po to, aby mieć tęczową tabelę dla jednego solonego+hashowanego hasła. Oznacza to, że jeśli masz 1 milion użytkowników, haker musi Wygeneruj 1 milion tęczowych tabel. Jeśli używasz tej samej soli dla każdego użytkownika, to haker musi wygenerować tylko 1 tęczową tabelę, aby skutecznie włamać się do systemu.

Jeśli nie wysyłasz haseł, to atakujący musi tylko wyciągnąć istniejącą tęczową tabelę dla każdej implementacji (AES, SHA-512, MD5) i sprawdzić, czy pasują one do hasha. To zostało już zrobione , atakujący nie musi obliczać tych tabel tęczowych siebie .

Nawet z tym wszystkim, musisz stosować dobre praktyki bezpieczeństwa . Jeśli uda im się z powodzeniem użyć innego wektora ataku (XSS, SQL Injection, CSRF, et. al.) na twojej stronie dobre zabezpieczenie hasłem nie ma znaczenia. To brzmi jak kontrowersyjne stwierdzenie, ale pomyśl o tym: jeśli Mogę uzyskać wszystkie informacje o użytkownikach za pomocą ataku SQL injection lub mogę zmusić użytkowników do przekazania mi swoich plików cookie za pośrednictwem XSS, to nie ma znaczenia, jak dobre są te informacje Twoje hasło to .

Inne zasoby:

    W związku z tym, że nie jest to możliwe, nie jest to możliwe.]}
  1. Jeff Atwood: I just logged in as you
  2. Jeff Atwood: prawdopodobnie błędnie przechowujesz hasła
  3. Jeff Atwood: Speed Hashing

Uwaga: Proszę polecić inne dobre zasoby. Musiałem przeczytać kilkanaście artykułów kilkudziesięciu autorów, ale niewielu pisze tak jasno na ten temat jak Jeff. Proszę edytować artykuły w miarę ich znajdowania.

 137
Author: George Stocker,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-04-12 07:31:22

Ty nie wolno używać BCrypt w .NET. Ty musisz używać PBKDF2 tak jak to jest z wbudowaną implementacją. NET framework. Jest to jedyna Darmowa, zweryfikowana kryptograficznie implementacja w.NET wraz z algorytmem zalecanym przez NIST.

StackId wcześniej używał BCrypt i przeniósł się do PBKDF2 z tego właśnie powodu:

Dla ciekawskich hashujemy hasła za pomocą PBKDF2. Kod Relavent jest tutaj ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), przez kilka warstw indrection. We wcześniejszej iteracji używali BCrypt; ale przenieśli się do PBKDF2, ponieważ jest wbudowany w. NET framework, natomiast BCrypt wymagałby od nas weryfikacji implementacji (nie małe przedsięwzięcie).

Kevin Montrose, Maj 27 2011

(Aktualizacja linku na Githubie)

Edit: znaczenie zweryfikowane w terminy kryptograficzne wydają się nie być łatwo zrozumiałe, zweryfikowana implementacja oznacza, że kryptograficznie udowodniono, że została zaimplementowana bez błędu. Koszt tego może łatwo osiągnąć $ 20,000 lub wyższe. Pamiętam to, kiedy robiłem badania nad OpenSSL i czytałem, gdzie stwierdzili, że nie ukończyli całego procesu weryfikacji, ale jeśli potrzebujesz w pełni zweryfikowane, że mogą wskazać Ci właściwą ścieżkę dla niego i wymienione koszty związane. Niektóre wymagania rządowe obejmują uprawnienia do weryfikacji algorytmów szyfrowania.

Implementacje bcrypt w. Net nie zostały zweryfikowane. Korzystanie z niezweryfikowanej implementacji szyfrowania nie może być absolutnie pewne, że nie ma w niej ani umyślnych złośliwych błędów, takich jak zezwolenie na backdoor do tego, co jest zaszyfrowane, ani niezamierzonych błędów implementacji, które skutkują niezabezpieczonymi kryptograficznie danymi.

2014 edit: dla każdego, kto kwestionuje imperatywność używania sprawdzonych algorytmy kryptopgraficzne patrzą na dewastację dokonaną przez heartbleed hack wyeksploatowany w OpenSSL. To jest koszt użycia niesprawdzonej implementacji. Jest zabezpieczony.... dopóki nie dowiesz się, że każda osoba może odczytać całą zawartość pamięci Twojego serwera.

Autor zmiany, która wprowadziła Heartbleed, Robin Seggelmann, stwierdził, że "przegapił walidację zmiennej zawierającej długość" i zaprzeczył, jakoby miał zamiar złożyć wadliwą wdrożenie. Po ujawnieniu Heartbleed, Seggelmann zasugerował skupienie się na drugim aspekcie, stwierdzając, że OpenSSL nie jest recenzowany przez wystarczającą liczbę osób.

Jest to definicja niesprawdzonej implementacji. Nawet najmniejsza wada może doprowadzić do okaleczenia całego zabezpieczenia.

2015 edit: usunięto język oparty na rekomendacjach i zastąpiono absolutami. Osadzony oryginalny komentarz Kevina Montrose ' a dla potomności.

 70
Author: Chris Marisic,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-08-10 14:29:04