#security #.net-3.5 #encryption #cryptography #passwords
#Безопасность #.net-3.5 #шифрование #криптография #пароли
Вопрос:
Я немного новичок в вопросах безопасности, особенно в криптографии.
В приложении, которое мы создаем(ASP.net приложение, созданное на платформе .NET 3.5), в настоящее время мы используем базы данных для сохранения аутентификационной информации наших пользователей (AD и т.д. На данный момент не подходит). Цель состоит в том, чтобы создать односторонний хэш паролей с использованием SHA256Managed при создании пользователя, а затем проверить пользователей, используя то же самое. В идеале мы не хотим использовать какие-либо сторонние библиотеки dll для алгоритма хеширования, за исключением случаев, когда это абсолютно необходимо, чтобы избежать ненужных зависимостей.
Вопросы:- 1. Есть ли вариант лучше, чем использовать односторонний хэш с соленым кодом? 2. Является ли SHA256 достаточно надежным / безопасным вариантом или нам следует рассмотреть что-нибудь еще? 3. Является ли управляемая sha256 реализация в системе.Криптография достаточно хороша с точки зрения скорости ит и т.д. Или мы должны рассматривать сторонние альтернативы ей?
Любые указания относительно подхода / реализации будут полезны.
Ответ №1:
В свое время я провел некоторое исследование по этому вопросу, и все пришли к выводу, что BCrypt — один из лучших способов создания одностороннего хэша.
Вы можете увидеть реализацию C # здесь: http://derekslager.com/blog/posts/2007/10/bcrypt-dotnet-strong-password-hashing-for-dotnet-and-mono.ashx
Кроме того, что приятно в BCrypt, так это то, что вы можете решить, сколько раундов вы хотели бы, чтобы он прошел.
Таким образом, вы можете сделать так, чтобы шифрование занимало около 1 секунды, например. Для пользователя это приемлемое время ожидания, но для того, кто пытается атаковать вас с помощью грубой силы, 1 секунда — это вечность.
Я не эксперт по безопасности, поэтому отнеситесь к тому, что я здесь говорю, как к недомолвке. Соль, которую вы можете отправить в свой метод BCrypt 🙂
Кроме того, вот несколько советов от Этвуда по этому поводу: http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
Обновить:
После ответа на этот вопрос NuGet значительно упростил использование BCrypt: http://nuget.org/packages ?q=bcrypt
Я не могу поручиться за какую-либо конкретную реализацию там, поэтому взгляните на код, но это должно значительно упростить использование и интеграцию BCrypt.
Комментарии:
1. Спасибо CubanX, я обязательно посмотрю BCrypt
2. Немного слабее, чем bcrypt, но уже является частью .net framework: PBKDF2-SHA-1 с использованием класса Rfc2898DeriveBytes .
Ответ №2:
- Да, сканирование сетчатки глаза (просто шучу). Хранение паролей в виде хэшей с помощью salt — правильный способ.
- SHA256 хорош. Очевидно, я не знаю, над каким типом приложения вы работаете, но SHA256 подходит для подавляющего большинства проектов. При необходимости вы всегда можете использовать более длинную длину ключа (384, 512). Проконсультируйтесь с вашим архитектором безопасности.
- Управляемый sha256 (мы говорим о .net, верно?) хорош. Мы используем его в наших проектах.
Пожалуйста, также подумайте о том, чтобы прочитать это: http://www.obviex.com/samples/hash.aspx
Комментарии:
1. ДА. Это реализация .NET, на которую я ссылался. Спасибо за ссылку.
2. Привет, поскольку существует предпочтение использованию алгоритмов, встроенных как часть . Я думаю, что это, возможно, тот вариант, который я пока использую для NET framework. Спасибо за помощь. Однако решение о том, использовать SHA256Managed / SHA512Managed или нет, еще не принято.
3. -1 за утверждение, что SHA-2 подходит для хэширования паролей. Это слишком быстро. Вместо этого используйте PBKDF2, bcrypt или scrypt.
4. хммм, я ответил на этот вопрос 2,5 года назад. SHA256 тогда считался хорошим. Я согласен, что алгоритмы хэширования паролей нужно выбирать с умом, и все ваши предложения верны (но Microsoft необходимо улучшить работу, чтобы все эти алгоритмы были легко доступны разработчикам как часть standard framework)
Ответ №3:
Да, в SHA256 нет ничего плохого, и, конечно же, SHA256Managed будет «достаточно быстрым» для большинства вариантов использования (я уверен, что вы не ожидаете проверки 1000 запросов на вход в секунду, и даже если бы это было так, остальная часть сайта все равно затмевала бы запросы на вход в систему …)
Но рассматривали ли вы элементы членства, встроенные в фреймворк? Они уже проделали всю тяжелую работу с точки зрения безопасного хранения учетных данных, а также реализации всех функций поддержки (таких как сброс пароля и т.д.)
Комментарии:
1. На самом деле … я слышал о членстве, но еще толком не изучил его. Ваш комментарий напомнил мне, что мне нужно. Спасибо! 🙂
Ответ №4:
Хранение хэшей паролей с помощью salt корректно. Однако легко ошибиться даже в этом. Конечно, прямо сейчас SHA256 будет держать злоумышленников в страхе, но дайте ему несколько лет. Внезапно SHA256 может показаться уже не таким безопасным. Вам необходимо использовать BCrypt, перспективный алгоритм хеширования.
Ответ №5:
Проблема с выполнением всего одного прохода SHA256 заключается в том, что он слишком быстрый, а один с отличным оборудованием может генерировать радужные таблицы для большого количества солей easily…to чтобы обойти это, вам нужно выполнить растяжение ключа….Я не собираюсь давать вам урок по растяжению ключа, но реализация bcrypt, о которой говорят люди, выполняет растяжение ключа. Если вам нужна более современная альтернатива bcrypt, которая использует HMACSHA256 или 512 в .NET, я рекомендую этот API: