Как выбрать соль для хеш-функции, предназначенной для защиты паролей?

Question

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

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

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

Является ли преимущество соли просто в том, чтобы сделать pw "более случайным" и, следовательно, победить стандартные радужные таблицы на основе словаря?

Были бы хорошие и практичные идеи:

1. Храните соль в отдельной базе данных - может быть, в отдельной системе, определенно с другим хостом, именем, pw и т. Д.
2. Создать соль на основе хэша имени пользователя (или имени + фамилии, или даты регистрации), предположительно с использованием другой хэш-функции? Тогда сама соль не будет сохранена в БД - только данные, используемые для ее вычисления ...
3. Сохраните в БД значение, которое объединяет хэшированный pw и соль неочевидным образом (например, соль - это 10 случайных ключей, и они вводятся в хэшированный pw между буквами 1 и 2, 4 и 5, 8 и 9, и т.д.).

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

Answer 1

1. затрудняет проверку паролей - не рекомендуется.
2. Лучше просто сгенерировать случайное число (достаточно 64-битного).
3. См. (Частично) SO 1191112 . Соль не должна быть секретной; это просто должно быть по-другому.

Чтобы ответить на ваш дополнительный вопрос: также проставьте идентификатор алгоритма (возможно, простое число, возможно, строку имени) вместе с данными. При обновлении вы хэшируете новые пароли, используя новый предпочтительный алгоритм, но вы сохраняете старый алгоритм до тех пор, пока все не изменят свои пароли и не останется сохраненных паролей, использующих старый алгоритм. Опять же, это не должно быть секретом - оно просто позволяет вам адаптироваться к изменениям в мире. Ясно, что если старый алгоритм внезапно становится бесполезным, вы думаете о том, можно ли использовать инкрементный подход. Но если что-то драматическое не произойдет, поэтапное использование нового механизма будет работать очень хорошо. Старайтесь не менять свой алгоритм так часто, чтобы у вас было три или более на ходу одновременно - хотя нет технической причины, по которой схема не может справиться с этим. Также попытайтесь спроектировать базу данных таким образом, чтобы размеры хэшей могли расти, не вызывая ошибок (поэтому оставьте место для расширения от 64 до 128 байт, или от 128 до 256, или ...).

Answer 2

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

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

Неважно, как вы собираете соль, если вы уверены, что она достаточно длинна. Согласно Википедии, 12-битный хэш (используемый старыми паролями Unix) чрезвычайно дорог, чтобы победить, но возможно. 128-бит (используется, например, MD5) слишком дорог, чтобы его можно было устранить в обозримом будущем.

Смотри также: http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables

Answer 3

Соли не секрет. Они могут храниться в открытом виде вместе с хешированной солью + паролем. Хэши засолены, чтобы избежать атак по словарю. Сольта со случайным значением, хранящимся вместе с паролем, или хеширование имени пользователя вместе с паролем, являются допустимыми вариантами. Однако я бы порекомендовал очень специфическую хеш-схему, а именно HTTP Digest HA1 хеш: user_name : realm : password. Это дает дополнительное преимущество, позволяющее аутентифицировать дайджест-вызовы HTTP. Именно эта аутентификация будет использоваться для автоматического доступа, как API-интерфейс REST вашего сайта.

Прежде чем приступить к осуждению использования MD5 вместо SHA1 (как того требует хэш схемы дайджеста HTTP), но обеспечение коллизии хеша MD5 по требованию для схемы дайджеста в обозримом будущем еще далеко от действия Не следует пренебрегать дополнительным преимуществом автоматического доступа (например, WebRequest, curl и т. д.).