Я читал, что при хешировании пароля многие программисты рекомендуют использовать алгоритм BCrypt.
Я программирую на C #, и мне интересно, знает ли кто-нибудь о хорошей реализации BCrypt? Я нашел эту страницу , но не знаю, поддельная она или нет.
На что следует обратить внимание при выборе схемы хеширования пароля? BCrypt - «хорошая» реализация?
Ответы:
Во-первых, некоторые важные термины:
Хеширование - процесс взятия строки и создания последовательности символов, которую нельзя вернуть к исходной строке.
Симметричное шифрование - (обычно именуемое просто «шифрованием») - действие по взятию строки и созданию последовательности символов, которая может быть расшифрована до исходной строки с использованием того же ключа шифрования, который ее зашифровал.
Rainbow Table - справочная таблица, которая содержит все варианты символов, хешированных с помощью определенного алгоритма хеширования.
Поваренная соль - известная случайная строка, добавляемая к исходной строке перед ее хешированием.
Для .NET Framework Bcrypt еще не имеет проверенной эталонной реализации. Это важно, потому что невозможно узнать, есть ли серьезные недостатки в существующей реализации. Вы можете получить реализацию BCrypt для .NET здесь . Я не знаю достаточно о криптографии, чтобы сказать, хорошая это реализация или плохая. Криптография - очень глубокая область. Не пытайтесь создать свой собственный алгоритм шифрования . Шутки в сторону.
Если вы собираетесь реализовать собственную защиту паролем (вздох), вам нужно сделать несколько вещей:
К сожалению, даже если вы сделаете все это, целеустремленный хакер все равно сможет вычислить пароли, это займет у него очень много времени. Это ваш главный враг: время .
Bcrypt алгоритм работает , потому что она занимает пять порядков больше , чтобы хэш пароля , чем MD5 ; (и все еще намного длиннее, чем AES или SHA-512). Это заставляет хакера тратить намного больше времени на создание радужной таблицы для поиска ваших паролей, что значительно снижает вероятность того, что ваши пароли будут под угрозой взлома.
Если вы солите и хешируете свои пароли, и каждая соль отличается, тогда потенциальному хакеру придется создать радужную таблицу для каждого варианта соли , просто чтобы иметь радужную таблицу для одного соленого + хешированного пароля. Это означает, что если у вас 1 миллион пользователей, хакер должен создать 1 миллион радужных таблиц. Если вы используете одну и ту же соль для каждого пользователя, то хакеру достаточно создать только одну радужную таблицу, чтобы успешно взломать вашу систему.
Если вы не солите свои пароли, то все, что нужно сделать злоумышленнику, - это открыть существующую таблицу Rainbow для каждой реализации (AES, SHA-512, MD5) и просто посмотреть, соответствует ли она хешу. Это уже сделано , злоумышленнику не нужно вычислять эти таблицы Rainbow самостоятельно .
Даже несмотря на все это, вы должны использовать хорошие методы безопасности . Если они могут успешно использовать другой вектор атаки (XSS, SQL-инъекция, CSRF и др. ) На вашем сайте, хорошая защита паролем не имеет значения. Это звучит как спорное утверждение, но думать об этом: Если я могу получить всю вашу информацию пользователя через инъекцию SQL атаку, или я могу получить ваши пользователь , чтобы дать мне свои кук через XSS, то это не имеет значения , насколько хорошо ваш пароль безопасность есть .
Другие источники:
Примечание. Порекомендуйте другие хорошие ресурсы. Я, должно быть, прочитал дюжину статей десятков авторов, но немногие пишут на эту тему так ясно, как Джефф. Пожалуйста, редактируйте статьи по мере их нахождения.
Вы не должны использовать BCrypt в .NET. Вы должны использовать PBKDF2 как есть со встроенной реализацией .NET framework. Это единственная свободно доступная криптографически проверенная реализация в .NET, а также алгоритм, рекомендованный NIST .
StackId ранее использовал BCrypt и перешел на PBKDF2 именно по этой причине:
Для тех, кому интересно, мы хэшируем пароли с помощью PBKDF2. Код Relavent находится здесь ( 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: Для тех, кто сомневается в необходимости использования проверенных криптографических алгоритмов, обратите внимание на опустошение, нанесенное хакерским взломом, использованным в OpenSSL. Это стоимость использования непроверенной реализации. Это безопасно ... пока вы не обнаружите, что любой человек может просто прочитать все содержимое памяти вашего сервера.
Автор изменения, которое представило Heartbleed, Робин Сеггельманн, заявил, что он «пропустил проверку переменной, содержащей длину», и отрицал какое-либо намерение представить некорректную реализацию. После раскрытия информации Heartbleed Сеггельманн предложил сосредоточиться на втором аспекте, заявив, что OpenSSL не проверяется достаточным количеством людей.
Это определение непроверенной реализации. Даже самый незначительный дефект может привести к нарушению всей безопасности.
Редактирование 2015: удален язык, основанный на рекомендациях, и заменен абсолютом. Встроенный оригинальный комментарий Кевина Монтроуза для потомков.