Есть ли какая-то ценность в солении и без того «надежного» пароля?

Question

Есть ли какая-либо польза от использования паролей для создания надежного, уникального (не используемого пользователем в других приложениях) пароля?

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

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

---

это теоретически. У меня нет склонности останавливать соление.

---

по сути, соль не становится просто частью пароля? просто он предоставляется привратником, а не пользователем.

Answer 1

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

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

Answer 2

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

Answer 3

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

Так как же ваше предположение (что надежные пароли не нуждаются в засолке) становится недействительным?

1) Со временем генерируются большие, более полные радужные таблицы. Это то, о чем я бы беспокоился, если ваш пользователь выберет надежный пароль. Они могут подумать, что проделали хорошую работу, а вы и ваша проверка безопасности могут подумать, что они тоже хорошо поработали, но позже выясняется, что их мыслительный процесс создания пароля был легко продублирован путем объединения нескольких слов и цифр.

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

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

Answer 4

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