В криптографии соль — это случайные данные, подаваемые в качестве дополнительных входных данных в одностороннюю функцию , которая хеширует данные , пароль или парольную фразу . [1] Соль помогает защититься от атак, использующих предварительно вычисленные таблицы (например, радужные таблицы ), значительно увеличивая размер таблицы, необходимой для успешной атаки. [2] [3] [4] Она также помогает защитить пароли, которые встречаются в базе данных несколько раз, поскольку для каждого экземпляра пароля используется новая соль. [5] Кроме того, соль не накладывает никакой нагрузки на пользователей.
Обычно для каждого пароля случайным образом генерируется уникальная соль. Соль и пароль (или его версия после растяжения ключа ) объединяются и передаются в криптографическую хэш-функцию , а выходное значение хэша затем сохраняется вместе с солью в базе данных. Соль не нужно шифровать, поскольку знание соли не поможет злоумышленнику. [5]
Соль широко используется в кибербезопасности: от учетных данных систем Unix до интернет-безопасности .
Соли связаны с криптографическими одноразовыми числами .
Без соли идентичные пароли будут соответствовать идентичным значениям хеша, что может облегчить хакеру подбор паролей по их значению хеша.
Вместо этого генерируется соль, которая добавляется к каждому паролю, в результате чего результирующий хеш выводит разные значения для одного и того же исходного пароля.
Затем соль и хэш сохраняются в базе данных. Чтобы позже проверить, является ли введенный пользователем пароль правильным, можно выполнить тот же процесс (добавив соль этого пользователя к паролю и вычислив полученный хэш): если результат не совпадает с сохраненным хешем, это мог быть неправильный введенный пароль.
На практике соль обычно генерируется с помощью криптографически безопасного генератора псевдослучайных чисел . CSPRNG предназначены для создания непредсказуемых случайных чисел, которые могут быть буквенно-цифровыми. Хотя обычно это не рекомендуется из-за низкой безопасности, некоторые системы используют временные метки или простые счетчики в качестве источника соли. Иногда соль может быть сгенерирована путем объединения случайного значения с дополнительной информацией, такой как временная метка или пользовательские данные, чтобы обеспечить уникальность в разных системах или временных периодах.
Использование одной и той же соли для всех паролей опасно, поскольку заранее рассчитанная таблица, которая просто учитывает соль, сделает ее бесполезной.
Генерация предварительно вычисленных таблиц для баз данных с уникальными солями для каждого пароля нецелесообразна из-за вычислительных затрат на это. Но если для всех записей используется общая соль, создание такой таблицы (которая учитывает соль) становится жизнеспособной и, возможно, успешной атакой. [6]
Поскольку повторное использование соли может привести к тому, что пользователи с одним и тем же паролем будут иметь одинаковый хеш, взлом одного хеша может привести к взлому и других паролей.
Если соль слишком короткая, злоумышленник может заранее вычислить таблицу всех возможных солей, добавленных к каждому вероятному паролю. Использование длинной соли гарантирует, что такая таблица будет непозволительно большой. [7] [8] 16 байт (128 бит) или более обычно достаточно для предоставления достаточно большого пространства возможных значений, что минимизирует риск коллизий (т. е. двух разных паролей с одинаковой солью).
Чтобы понять разницу между взломом одного пароля и набора паролей, рассмотрим файл с пользователями и их хешированными паролями. Допустим, файл не содержит соли. Тогда злоумышленник может выбрать строку, назвать ее attempt[0], а затем вычислить hash(attempt[0]). Пользователь, хеш которого хранится в файле , hash(attempt[0])может иметь или не иметь пароль attempt[0]. Однако даже если attempt[0]это не фактический пароль пользователя, он будет принят так, как если бы он был таковым, потому что система может проверять пароли, только вычисляя хеш введенного пароля и сравнивая его с хешем, сохраненным в файле. Таким образом, каждое совпадение взламывает пароль пользователя, и вероятность совпадения возрастает с количеством паролей в файле. Напротив, если используются соли, злоумышленнику придется вычислять hash(attempt[0] || salt[a]), сравнивать с записью A, затем hash(attempt[0] || salt[b]), сравнивать с записью B и т. д. Это предотвращает любую попытку взлома нескольких паролей, учитывая, что повторное использование соли исключается. [9]
Соли также борются с использованием предварительно вычисленных таблиц для взлома паролей. [10] Такая таблица может просто сопоставлять общие пароли с их хэшами или может делать что-то более сложное, например, хранить начальные и конечные точки набора предварительно вычисленных цепочек хешей . В любом случае, соление может защитить от использования предварительно вычисленных таблиц, удлиняя хеши и заставляя их извлекать из более крупных наборов символов, что снижает вероятность того, что таблица покроет полученные хеши. В частности, предварительно вычисленная таблица должна будет покрывать строку, [salt + hash]а не просто [hash].
Современная система теневых паролей , в которой хэши паролей и другие данные безопасности хранятся в непубличном файле, несколько смягчает эти опасения. Однако они остаются актуальными в многосерверных установках, которые используют централизованные системы управления паролями для передачи паролей или хэшей паролей в несколько систем. В таких установках учетная запись root в каждой отдельной системе может рассматриваться как менее доверенная, чем администраторы централизованной системы паролей, поэтому по-прежнему стоит гарантировать, что безопасность алгоритма хэширования паролей, включая генерацию уникальных значений соли, является адекватной. [ необходима цитата ]
Другое (меньшее) преимущество соли заключается в следующем: два пользователя могут выбрать одну и ту же строку в качестве своего пароля. Без соли этот пароль будет сохранен как одна и та же хэш-строка в файле паролей. Это раскроет тот факт, что у двух учетных записей один и тот же пароль, что позволит любому, кто знает пароль одной из учетных записей, получить доступ к другой учетной записи. При добавлении соли в пароли с помощью двух случайных символов, даже если две учетные записи используют один и тот же пароль, никто не сможет узнать это, просто прочитав хэши. Использование соли также чрезвычайно затрудняет определение того, использовал ли человек один и тот же пароль для нескольких систем. [11]
Более ранние версии Unix использовали файл паролей /etc/passwd для хранения хэшей соленых паролей (паролей с префиксом из двухсимвольных случайных солей). В этих старых версиях Unix соль также хранилась в файле passwd (в виде открытого текста) вместе с хешем соленого пароля. Файл паролей был доступен для чтения всем пользователям системы. Это было необходимо для того, чтобы привилегированные программные инструменты пользователя могли находить имена пользователей и другую информацию. Поэтому безопасность паролей защищена только односторонними функциями (шифрованием или хешированием), используемыми для этой цели. Ранние реализации Unix ограничивали пароли восемью символами и использовали 12-битную соль, что допускало 4096 возможных значений соли. [12] Это был подходящий баланс для вычислительных и складских затрат 1970-х годов. [13]
Система теневых паролей используется для ограничения доступа к хэшам и соли. Соль состоит из восьми символов, хэш — из 86 символов, а длина пароля фактически не ограничена, за исключением ошибок переполнения стека.
Обычно веб-приложения хранят в базе данных хэш-значение пароля пользователя. Без соли успешная атака с использованием SQL-инъекции может привести к получению легко взламываемых паролей. Поскольку многие пользователи повторно используют пароли для нескольких сайтов, использование соли является важным компонентом общей безопасности веб-приложений . [14] Некоторые дополнительные ссылки по использованию соли для защиты хэшей паролей в определенных языках или библиотеках (PHP, библиотеки .NET и т. д.) можно найти в разделе внешних ссылок ниже.
{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка ){{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )