Насколько безопасно хранить соли вместе с хешированным паролем

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

dbo.aspnet_Membership

ApplicationId
UserId
Password
PasswordFormat
PasswordSalt
MobilePIN
Email
. . .

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

Связанные

Являются ли соли бесполезными для безопасности, если злоумышленник знает их?

Ответ 1

Для специфики хранилища паролей/хешей/солей ASP.NET см., например, http://msdn.microsoft.com/en-us/library/aa478949.aspx

Злоумышленнику "разрешено" знать соль - ваша безопасность должна быть спроектирована таким образом, чтобы даже с уверенностью в том, что соль по-прежнему безопасна.

Что делает соль?

Соль помогает в защите от нападений грубой силы с использованием предварительно вычисленных "радужных столов".
Соль делает грубую силу намного дороже (во времени/памяти) для атакующего.
Вычисление такой таблицы является дорогостоящим и обычно выполняется только тогда, когда оно может использоваться для нескольких атак/паролей.
Если вы используете ту же соль для всего пароля, злоумышленник может предварительно вычислить такую таблицу, а затем перетащить ваши пароли в cleartext...
Пока вы создаете новую (лучшую криптографически сильную) случайную соль для каждого пароля, который вы хотите сохранить хэш, нет проблем.

ЕСЛИ вы хотите усилить безопасность дальше
Вы можете рассчитать хэш несколько раз (хеш-хэш и т.д.) - это вам не дорого, но делает более грубую атаку/расчет "радужных столов"... пожалуйста, не изобретайте себя - для этого существуют проверенные стандартные методы, см., например, http://en.wikipedia.org/wiki/PBKDF2 и http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

ПРИМЕЧАНИЕ.

Использование такого механизма в наши дни имеет мандат, так как "время процессора" (применимое для атак, таких как радужные таблицы/грубая сила и т.д.) становится все более доступным (см., например, тот факт, что сервис Amazon Cloud является одним из лучших 50 самых быстрых суперкомпьютеров по всему миру и могут быть использованы кем-либо за сравнительно небольшую сумму)!

Ответ 2

Целью солей является замедление, а не предотвращение прямой, возможность взлома базы данных. Но это значительно замедляет хакер! От нескольких секунд до, в зависимости от алгоритма, длины соли и других факторов, часов, месяцев или лет жизни.

Тем не менее, вы должны хранить соли с солеными паролями, иначе невозможно проверить пароли после факта.

Есть несколько вещей, которые вы можете сделать, чтобы сделать все это более безопасным:

Никогда не используйте ту же соль. Он должен отличаться для каждого пароля.
Используйте длинную соль. GUID, как правило, является популярным вариантом. Я обычно генерирую их, получая хеш MD5 для случайного числа
Если вы хотите, вы можете запустить свой алгоритм хеширования более одного раза. Это удлиняет время, необходимое для перебора пароля.

Ответ 3

Я бы не использовал MD5 SHA1 намного безопаснее. Но, если честно, если вы знаете что-то о безопасности и криптографии, это односторонние функции. Поэтому, как ни странно, никто не потеряет столько своего времени, чтобы атаковать что-то, что не даст ему денег: D. Если вы считаете, что это небезопасно, используйте RSA, но используйте очень-очень-очень длинный номер в качестве ключа.