Ответ 1
У вас есть это, это первый.
Если вы только конкатенировали соль и хэш, тогда атакующий может просто удалить "соль" и использовать радужный стол. Путем хэширования открытого текста + соли соль не может быть вычтена.
Что, во-первых, соль или хэш?
Хорошо, я знаю, что это, вероятно, мертво просто, но я не могу найти прямой ответ нигде. Скажем, у меня есть следующее:
Password: "mypassword"
Salt: 1234567
Есть ли идея соления сделать что-то вроде hash(password + salt) или hash(password) + salt? Я предполагаю, что только первый имеет смысл вообще, но я просто хочу убедиться, что я что-то не пропустил.
Прошу простить мое невежество.
Ответы
Ответ 2
Собственно, он salt + hash(salt+password) (Соль является частью вычисления хеша - но вы также должны держать его в ясном)
Ответ 3
хеш (пароль + соль). Если вы конкатенируете соль после хэширования, конкатенация легко обратима и не создает никаких трудностей с изменением хэша на пароле (с радужными таблицами).
Тем не менее, некоторые системы выполняют оба, например. Django хранит соль $hash (соль + пароль) в базе данных. Это просто так, что каждая часть данных, необходимая для проверки пароля на хэш, доступна в одном месте.
Ответ 4
Я добавляю эти ссылки в этот вопрос для полноты - эта тема соленого хеширования требует широкого понимания тем, которые кормят в ней, чтобы избежать дорогостоящих ошибок.
Ключевой момент, не совсем выраженный в ответах здесь, заключается в необходимости использования уникальной соли для каждого пароля. Подробнее о том, почему, читайте связанные элементы.
Почему каждая соль уникальна: Солить свой пароль: лучшие практики?
Широкий обзор по теме: Солярное ПО и программное обеспечение с открытым исходным кодом
Ответ 5
Соль должна быть частью расчета хеша