Соление Вашего пароля: лучшие практики?

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

То, что это, там, как предполагается, побеждает таблицы радуги.

Модель угрозы, на которую я сослался, будет сценарием, где у противника могут быть таблицы радуги общих солей, добавлял/предварительно ожидал к паролю. (Скажите NSA), Вы предполагаете их или добавили его или предварительно ожидаемый, но не оба. Это глупо, и это - плохое предположение.

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

Как я сказал. Это - семантика. Выберите другую соль на пароль, длинную соль, и включайте нечетные символы в него как символы и коды ASCII: ¤ © ¡

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

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

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

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

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

@onebyone.livejournal.com:

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

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

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

Кроме того, алгоритмы хеширования пароля как PBKDF составляют свою хеш-функцию многократно (рекомендуется выполнить итерации PBKDF-2 минимум 1 000 раз, каждый итеративный SHA-1 применения дважды), делающий это нападение, вдвойне непрактичное.

BCrypt хешируют, если платформа имеет поставщика. Я люблю, как Вы не волнуетесь о создании солей, и можно сделать их еще более сильными, если Вы хотите.

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