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

Question

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

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

На что следует обратить внимание при выборе схемы хеширования паролей?Является ли BCrypt «хорошей» реализацией?

Answer 1

Сначала несколько важных терминов:

Хеширование — Действие по взятию строки и созданию последовательности символов, которую невозможно вернуть к исходной строке.

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

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

Соль — известная случайная строка, добавляемая к исходной строке перед ее хешированием.

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

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

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

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

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

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

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

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

Другие источники:

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

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