Соль (также модификатор входа хэш-функции ) — строка данных, которая передаётся хеш-функции вместе с входным массивом данных ( прообразом ) для вычисления хэша ( образа ).

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

Пример использования

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

Пример создания хеша с использованием статичной соли на языке PHP по принципу конкатенации (соединения) с входными данными:

  $password1 = '12345';
  $password2 = '67890'; 
  $salt = 'sflpr9fhi2'; // «Соль»
  $password1_saltedHash = md5($password1 . $salt); // Соединяем входную строку с «солью» и пропускаем через хэш-функцию md5()
  $password2_saltedHash = md5($password2 . $salt);

В данном примере соль является детерминированной строкой, то есть значение соли постоянно для всех входных данных.

Динамическая соль

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

Один из известных стандартов PBKDF2 описывает подмешивание соли в несколько итераций.

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

Проблемы, связанные с солью и надёжностью паролей

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

При плохо продуманной системе применения соли её преимущества теряются:

Малая длина соли и низкая энтропия

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

Повторное использование соли для разных прообразов

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

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

Преимущества использования соли в системах авторизации

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

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

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

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

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

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

Соль в системах UNIX

В большинстве UNIX -систем в качестве односторонней функции используется системная библиотека crypt(3) . Изначально эта библиотека использовала хеш-функцию на базе алгоритма DES . При этом пароль был ограничен 8 символами (по 7 бит на символ, то есть 56 бит), и использовалась 12-битная соль .

В 1994 году Пул-Хеннинг Кэмп на базе MD5 создал новый алгоритм хеширования паролей, который позволял использовать пароли любой длины и использовал тысячу итераций MD5 . Результатом работы функции стала строка, содержащая метку алгоритма хеширования (версию), соль и хеш.

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

Сейчас библиотека поддерживает несколько хеш-функций на базе алгоритмов: MD5 , SHA-256 , SHA-512 , Blowfish (в некоторых дистрибутивах Linux , OpenBSD и некоторых других UNIX-подобных системах) . Результатом работы функции является строка, содержащая метку алгоритма хеширования, соль, хеш и другие данные (например, число раундов хеш-функции).

В 2012 году Пул-Хеннинг Кэмп призвал полностью отказаться от созданного им алгоритма md5crypt, как не обеспечивающего в современных условиях ощутимого увеличения времени вычисления хеша, а значит, и не защищающего от полного перебора .

См. также

• Хеш-функция
• Сложность пароля
• Информационная энтропия
• Радужная таблица
• Хеш-таблица
• Конкатенация
• Полный перебор
• Перебор по словарю
• PBKDF2
• Crypt (Unix)

Примечания

Литература

• Robert Morris, Ken Thompson. (англ.) // Communications of the ACM : журнал. — ACM New York, NY, USA, 1979. — Vol. 22 , no. 11 . — P. 594—597 .
• B. Kaliski. (англ.) (сентябрь 2000). Дата обращения: 13 июня 2012. 2 июля 2012 года.