Где хранить соль для паролей и как ее получить

Я отвечаю за аутентификацию в нашем веб-приложении .Net MVC 4, и я столкнулся с проблемой хеширования, хранения и аутентификации паролей.

В настоящее время планируется использовать 2 соли, 1 динамический (для каждого пользователя) и 1 статический (константа веб-приложения), а также сильную функцию хеширования.

Учитывая простую таблицу User, содержащую имя пользователя и пароль:

  • Могу ли я хранить соль для каждого пользователя в столбце таблицы пользователей?

Меня беспокоит, что при этом мне придется получать пользователя из базы данных в памяти веб-приложения только с его именем пользователя. Есть ли какая-то атака, при которой это может быть проблематично? В идеале я бы хотел, чтобы это была аутентификация в один шаг / один запрос SQL.

Я слишком сильно волнуюсь? Есть ли альтернатива соли "на пользователя", при которой я все еще могу выполнять одноэтапную аутентификацию?


person Alexandre    schedule 09.07.2013    source источник
comment
Также сходство: stackoverflow.com/ questions / 1219899 /   -  person user956584    schedule 18.06.2015


Ответы (2)


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

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

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

person martinstoeckli    schedule 09.07.2013
comment
Большое спасибо. Я использовал библиотеку SimpleCrypto.Net для методов хеширования PBKDF2. Я буду дальше изучать перец. - person Alexandre; 12.07.2013

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

person Marcus Classon    schedule 13.07.2013