Лучше ли засолить строку при создании безопасного хэша?

Question

Я не очень силен в криптографии, поэтому есть мой вопрос.

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

Для этого я решил просто подписать запрос с SHA1, например:

http://example.com/unsubscribe?u=234&s=52342&h=0b071440146545eaf3f00ef9cdeb1d47d006dfff

Здесь u - это идентификатор пользователя, который хочет отписаться, s - некоторая случайная соль, h - безопасный хеш, рассчитанный путем объединения имени действия (отписаться), параметров и их значений. (u = 234s = 52342) и некоторую секретную строку, указанную в конфигурации нашего сервиса и вычисляющую хеш SHA1 для полученной строки:

sha1('unsubscribeu=234s=52342supersecret')

Мой вопрос об этом параметре s, который генерируется случайным образом каждый раз. Это добавляет к безопасности здесь или нет? Это действительно нужно?

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

Это скорее теоретический вопрос, поскольку очень маловероятно, что кто-то захочет догадаться, что «суперсекрет» в нашем сервисе просто разыграть-отписать группу пользователей, но все же интересно.

Answer 1

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

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

Answer 2

То, что вы хотите, это не соль, а скорее nonce .Используя одноразовый номер и записывая факт его использования, вы можете ограничить риск, связанный с раскрытием секретного URL.

Кроме того, вместо объединения своего секрета с хешированной строкой используйте HMAC .

Answer 3

Я ни в коем случае не эксперт по безопасности, но думаю, что могу оставить свои 2 цента.

Параметр «S» (т. Е. «Соль», как вы его называете) является токеном безопасности и является вашей основной мерой безопасности.Хэш предназначен для того, чтобы сделать управление параметрами URL более сложным (или даже невозможным), чтобы конечный пользователь не мог запускать действия с другим токеном при аналогичном вызове.

Вы, вероятно, должны хранить токен вместе сотменить запрос пользователя и проверить равенство при последующем вызове подтверждения (проверка действия отказа пользователя).После проверки хеша параметров URL, конечно (проверка, если запрос не обрабатывается)