Является ли BCrypt хорошим алгоритмом хэширования для использования в C#? Где я могу его найти? [закрытый]

Я читал, что при хешировании пароля многие программисты рекомендуют использовать алгоритм BCrypt.

я программирую на C# и задаюсь вопросом, знает ли кто-нибудь о хорошей реализации для BCrypt? Я нашел на этой странице, но я действительно не знаю, является ли это фикцией или нет.

Что я должен знать при выборе схемы хэширования паролей? Является ли BCrypt "хорошей" реализацией?

2 ответов


во-первых, некоторые термины, которые являются важными:

хеширования - акт взятия строки и создания последовательности символов, которые не могут быть возвращены к исходной строке.

Симметричное Шифрование - (обычно просто называется "шифрование") - акт принятия строки и создания последовательности символов, которые can быть расшифрованы в исходную строку с помощью той же ключ шифрования, который его зашифровал.

Радужный Таблице - таблица поиска, содержащая все варианты символов, хэшированных в определенном алгоритме хэширования.

соль - известная случайная строка, добавленная к исходной строке до ее хэширования.

для .NET Framework Bcrypt еще не имеет проверен эталонной реализации. Это важно, потому что нет никакого способа знать, есть ли серьезные недостатки в существующей реализации. Вы можете получить реализацию BCrypt для .NET здесь. Я не знаю достаточно о криптографии, чтобы сказать, является ли это хорошей или плохой реализации. Криптография-очень глубокая область. не пытайтесь построить свой собственный алгоритм шифрования. Серьезно.

Если вы собираетесь реализовать свою собственную безопасность паролей (вздох), то вам нужно сделать несколько вещей:

  1. использовать a относительно безопасный алгоритм хэша.
  2. Соль каждый пароль, прежде чем он хэшируется.
  3. использовать уникальная и длинная соль для каждого пароля, и хранить соль с паролем.
  4. требуются надежные пароли.

к сожалению, даже если вы сделаете все это, решительный хакер все еще может потенциально выяснить пароли, это займет у него очень много времени. Это твой главный враг: времени.

на алгоритм bcrypt работает, потому что он принимает пять порядки величины дольше хэшировать пароль, чем MD5; (и все еще гораздо длиннее, чем AES или SHA-512). Это заставляет хакера тратить гораздо больше времени на создание радужной таблицы для поиска ваших паролей, что делает его гораздо менее вероятным, что ваши пароли будут под угрозой взлома.

Если ты солить и хэширования паролей, и каждый соли отличается, тогда потенциальный хакер должен был бы создать радужную таблицу для каждого варианта соли, просто иметь радужную таблицу для одного соленого + хэшированного пароля. Это означает, что если у вас есть 1 миллион пользователей, хакер должен создать 1 миллион радужных таблиц. Если вы используете одну и ту же соль для каждого пользователя, хакеру нужно создать только 1 таблицу rainbow, чтобы успешно взломать вашу систему.

Если вы не солите свои пароли, то все, что должен сделать злоумышленник, это вытащить существующая радужная таблица для каждой реализации (AES, SHA-512, MD5) и просто посмотрите, соответствует ли она хэшу. Это уже выполнена злоумышленник не нужно вычислять эти радужные таблицы сами.

даже со всем этим,вы должны использовать хорошие методы безопасности. Если они могут успешно использовать другой вектор атаки (XSS, SQL Injection, CSRF,et. Эл.) на вашем сайте хорошая защита паролем не имеет значения. Это звучит как спорное утверждение, но подумайте об этом: если я могу получить всю вашу пользовательскую информацию через атаку SQL-инъекции, или я могу заставить ваших пользователей дать мне свои куки через XSS,тогда не имеет значения, насколько хороша ваша безопасность пароля.

другие ресурсы:

  1. Джефф Этвуд: упрощенное шифрование .NET (большой обзор майнинга)
  2. Джефф Этвуд: я только что вошел в систему как вы
  3. Джефф Этвуд: вы, вероятно, неправильно храните пароли
  4. Джефф Этвуд: Скорость Хеширования

Примечание: пожалуйста, порекомендуйте другие хорошие ресурсы. Я, должно быть, прочитал дюжину статей десятков авторов, но немногие пишут на эту тему так ясно, как Джефф. Пожалуйста, Редактируйте статьи по мере их нахождения.


вы нельзя использовать осуществляется в .Чистая. Вы вы должны использовать PBKDF2 как со встроенной реализацией .NET framework. Это единственная свободно доступная криптографически проверенная реализация в .NET наряду с алгоритм, рекомендованный NIST.

StackId ранее использовал BCrypt и перешел на PBKDF2 именно по этой причине:

для тех, кто любопытен, мы хэшируем пароли с PBKDF2. Код перелистывая быть здесь ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), через несколько слоев абстракции. В более ранней итерации, мы использовали BCrypt; но переместились в PBKDF2, поскольку он встроен в .NET framework, в то время как BCrypt потребует от нас проверки реализации (не малое предприятие).

Кевин Монтроуз, 27 Мая 2011

(обновлена ссылка на GitHub)

изменить: смысл проверен в криптографических терминах, кажется, не легко понять, проверенная реализация означает, что она была криптографически доказана без ошибок. Стоимость этого может легко достигать $ 20,000 или выше. Я помню это, когда я проводил исследование OpenSSL и читал, где они заявили, что не завершили весь процесс проверки, но если вам нужно полностью проверить, что они могут указать вам на верном пути к этому и упомянутые расходы. Некоторые требования правительства включают мандаты для проверенных алгоритмов шифрования.

реализации bcrypt в .NET не были проверены. Используя непроверенную реализацию шифрования, вы не можете быть абсолютно уверены, что в ней нет преднамеренных вредоносных ошибок, таких как разрешение бэкдора в зашифрованное или непреднамеренные ошибки реализации, которые приводят к криптографически небезопасным данные.

2014 edit: для тех, кто сомневался в императивности использования проверенных криптопграфических алгоритмов, посмотрите на опустошение, которое было вызвано heartbleed hack используется в OpenSSL. Это стоимость использования непроверенной реализации. Это безопасно.... пока вы не узнаете, что любой человек может просто прочитать все содержимое памяти вашего сервера.

автор изменения, которое ввело Heartbleed, Робин Сеггельманн заявил, что он" пропустил проверку переменной, содержащей длину", и отрицал любое намерение представить дефектную реализацию. После раскрытия Heartbleed Сеггельман предложил сосредоточиться на втором аспекте, заявив, что OpenSSL не рассматривается достаточным количеством людей.

Это определение непроверенной реализации. Даже самый маленький дефект может привести к повреждению всей безопасности.

2015 edit: удалил рекомендации основаны на формулировках и заменены абсолютными. Встроенный оригинальный комментарий Кевина Монтроуза для потомков.