Веб-приложение - хранение пароля

Question

Я что-то пропустил?Есть ли дополнительные шаги по сохранению паролей к БД?

Хранение пароля: Проведя как можно больше исследований по этому вопросу, я пришел к выводу, что лучший способ хранения пользовательских паролей в БД веб-приложения (в моем случае MySQL + PHP) заключается в следующем:

• Назначьте статическую соль для всего тела.(16 рандовых символов, включая 0-9, az, AZ, [] / * - ')
• Назначение случайной соли для каждого пользователя (сохраненной в БД).
• Сохранение результата hash_function ($ userPassword + $ sitewideSalt + $ randomSalt)
• Сохранять $ randomSalt вместе с полученным хешем.
• Использовать регулируемое хэширование bcrypt для рабочей нагрузки

---

• Атака №1: Атакующий создает дамп БД через SQL-инъекцию. Результаты БД нашей хэш-функции и случайной соли для каждого пользователя.

  После сброса злоумышленник может получить $ userPassword и $ randomSalt , просмотрев свой собственный аккаунт.Затем, угадав хеш-функцию, такую ​​как md5, он может начать радужную атаку на $ sitewideSalt .Но это может занять до 1,41 сотни миллионов веков [1].

  Использование этого типа защиты не позволяет дампу БД подвергать риску хранимые пароли ,Пользователь все еще должен найти $ sitewideSalt другим способом.

• Атака № 2: Атакующий находит вектор локального включения файла (LFI).
  Атакующий может получить необработанный код для нашеговеб приложение.После использования веб-приложения через возможный LFI или RFI [2] злоумышленник считывает исходный код нашего веб-приложения и получает наш простой алгоритм и сохраненный
  $ sitewideSalt .

Куда дальше? Теперь у злоумышленника есть обе соли, которые он может начать радовать, чтобы получить действительные пароли.За исключением того, что он должен сделать 1 радужную таблицу для каждого пользователя, поскольку у каждого пользователя есть разные соли для случайных пользователей ($ randomSalt).

"Современный сервер может вычислять хэш MD5 примерно 330 МБ каждую секунду. Если у ваших пользователей есть пароли, состоящие из строчных, буквенно-цифровых символов и длиной 6 символов, вы можете использовать любой возможный пароль такого размера.примерно за 40 секунд. "«... CUDA, вы можете собрать свой собственный небольшой суперкомпьютерный кластер, который позволит вам пробовать около 700 000 000 паролей в секунду ...» [3]

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

1. http://www.grc.com/haystack.htm
2. http://www.wildcardsecurity.com/security101/index.php?title=Local_File_Inclusion

Answer 1

Отличная работа!Выглядит очень полным для меня.

Единственные предложения, которые у меня были бы:

Поворот служебной соли.

Разработка метода периодического поворота службыобщепринятая соль и выполняйте ее регулярно.

Например, после создания новой сервисной соли используйте ее для всех новых учетных записей и любых изменений пароля.Когда существующий пользователь пытается войти в систему, аутентифицируйте его со старой солью сервиса.В случае успеха обновите их хеш новой солью сервиса (и, возможно, новой солью, специфичной для пользователя).Для пользователей, которые не входят в систему «некоторое время», случайным образом сгенерируйте новый пароль от их имени.Это будет «поддерживать» безопасность для пользователей, которые покинули ваш сайт, заставляя тех, кто возвращается, использовать средства сброса пароля.(«Некоторое время» = любой период, который вам удобен).

Не задавайте жестко код вашей сервисной соли.

Не разрешайте атаку LFIпоставить под угрозу вашу соль обслуживания.Подайте сервисную соль вашему приложению при запуске и сохраните его в памяти.Чтобы скомпрометировать служебную соль, злоумышленник должен иметь возможность выполнять код для чтения соли из памяти.Если злоумышленник может это сделать, вы все равно будете в хорошей форме.=)

Не используйте соль пользователей повторно.

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

(Отметьте это как вики сообщества, если у других появятся дополнительные идеи).

Answer 2

Использование BCrypt для обработки паролей является единственным шагом, или, скорее, включает в себя следующее:

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

Вы также забыли эту ссылку: http://codahale.com/how-to-safely-store-a-password/, на которую вы ссылаетесь в цитате.