Это очень сильно зависит от размера пространства поиска. Например, мы могли бы сделать вид, что номера социального страхования являются случайными и уникальными (на самом деле они тоже не являются, но для целей этого обсуждения мы будем делать вид, что они есть). Если вы хэшируете SSN, вам нужна не только соль, но и соли недостаточно. Зачем? Потому что существует менее 10 миллиардов SSN. Создание радужного стола для них тривиально. Даже с солью не так-то просто перебрать силу, даже если значения уникальны и случайны.
Таким образом, чтобы защитить случайное и уникальное значение, которое находится в небольшом пространстве поиска, мы должны использовать алгоритм растяжения, такой как PBKDF2, а не просто хеш. Смысл алгоритма растяжения заключается в том, чтобы вычислить хеш очень медленно.
Алгоритмы растяжения всегда включают соль. Но это не обязательно случайная соль. Это может быть детерминированным (некоторый идентификатор базы данных + идентификатор пользователя, например, «com.example.mygreatapp: alice»). Но для небольшого пространства поиска вам все равно нужно, чтобы он был уникальным для каждого пользователя, поскольку в пространстве поиска очень мало элементов.
С другой стороны, если ваши случайные и уникальные данные представляют собой большое пространство поиска (не менее 2 ^ 64, а в идеале не менее 2 ^ 80), и это пространство поиска редкое (вы используете только очень небольшую часть юридических элементов), то засолка и растяжение, скорее всего, не требуются.