Должен ли я хранить соль в том же столбце, что и мой хэш?

Question

Итак, я крут с использованием соли для каждого пользователя для хеширования паролей моих пользователей.Однако в принятом ответе :

есть один совет: не используйте отдельный столбец для соли.

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

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

Answer 1

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

Я думаю, что этот комментарий указывал (хотя и плохо) на то, что альтернативным решением является получение соли из другого фрагмента данных для пользователя, производной соли .

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

Теперь, если злоумышленник имеет полный доступ как к таблице паролей, так и к исходному коду, вы не получаете никакой защиты, однако, если атака имеет только доступ к базе данных (ограниченное вторжение), вы прекратили атаку или, по крайней мере, сделаете ее намного более сложной.

Еще один аспект, который следует учитывать при реализации производной соли, заключается в том, сможет ли ваш злоумышленник создать учетную запись пользователя (открытая система регистрации). Если кто-либо (включая вашего злоумышленника) может создать учетную запись (как, например, в stackoverflow), производная соль имеет меньшую ценность. Зачем? Злоумышленник может выполнить обратный инжиниринг соли и, следовательно, источника соли, имея только доступ к базе данных посредством атаки открытым текстом (злоумышленник знает свой собственный пароль и другие сведения).

Answer 2

Ответ безопасности состоит в том, что это не имеет значения.

Ответ базы данных состоит в том, что соль и хеш - это разные величины, поэтому в идеале вы должны хранить их в разных столбцах.Если вы сделаете это, то можно будет сказать, что база данных нормализована .

Однако, нередко денормализует базу данных для повышения скорости доступа - объединяет хэши соль в том же столбце может служить примером денормализации.

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

Answer 3

Я думаю, что вторая часть первого ответа (часть о «динамической соли») в этой теме дает ответ, который вы ожидаете: создать случайную соль для каждого пользователя и сохранить ее с хешированным паролем. Это именно то, что UNIX passwd (и более поздние теневые) файлы делали десятилетиями.

Существует некоторая путаница в этой теме о том, что именно соль . В некоторых ответах дано очень общее определение в виде «любого известного текста, смешанного с паролем перед выполнением одностороннего хеширования». Существует множество причин смешивать известный текст и секретный текст перед выполнением одностороннего хеширования, и очевидно, что обработка известного текста в таких случаях будет зависеть от алгоритма. В качестве примера рассмотрим http://en.wikipedia.org/wiki/CRAM-MD5, в котором пользователь вообще не отправляет свой пароль по сети, хешируя его с помощью «соли», указанной сервером.