Введение
Случайные данные, используемые в качестве дополнительного ввода в хеш-функцию.
В криптографии соль — это случайные данные, передаваемые в качестве дополнительного ввода в одностороннюю функцию, которая хеширует данные, пароль или парольную фразу. Соль помогает защититься от атак, использующих предварительно вычисленные таблицы (например, радужные таблицы), значительно увеличивая размер таблицы, необходимый для успешной атаки. Она также помогает защитить пароли, которые многократно встречаются в базе данных, поскольку для каждого экземпляра пароля используется уникальная соль. Соль широко применяется в сфере кибербезопасности, от учетных данных систем Unix до интернет-безопасности. Соли связаны с криптографическими одноразовыми номерами (но́нсами).
Повторное использование соли
Использование одной и той же соли для всех паролей опасно, поскольку предварительно вычисленная таблица, учитывающая эту соль, сделает её бесполезной. Создание предварительно вычисленных таблиц для баз данных с уникальными солями для каждого пароля нецелесообразно из-за высоких вычислительных затрат. Однако, если для всех записей используется общая соль, создание такой таблицы (учитывающей соль) становится возможной и потенциально успешной атакой. Повторное использование соли может привести к тому, что пользователи с одинаковыми паролями будут иметь одинаковые хеши, и взлом одного хеша может привести к компрометации и других паролей.
Длина соли
Если соль слишком короткая, злоумышленник может предварительно вычислить таблицу всех возможных солей, добавленных ко всем вероятным паролям. Использование длинной соли гарантирует, что создание такой таблицы будет непомерно затратным.
Преимущества
Чтобы понять разницу между взломом одного пароля и набора паролей, рассмотрим файл с пользователями и их хэшированными паролями. Предположим, файл не использует соль. Тогда злоумышленник может выбрать строку, назовём её `attempt`, и вычислить её хэш. Пользователь, чей хэш хранится в файле, может иметь пароль, соответствующий этому хэшу, а может и не иметь. Однако, даже если `attempt` не является фактическим паролем пользователя, он будет принят как верный, потому что система может проверять пароли только путём вычисления хэша введённого пароля и сравнения его с хэшем, хранящимся в файле. Таким образом, каждое совпадение взламывает пароль пользователя, и вероятность совпадения возрастает с увеличением количества паролей в файле. В отличие от этого, если используются соли, злоумышленнику придётся вычислить hash(`attempt` || salt[a]), сравнить с записью A, затем hash(`attempt` || salt[b]), сравнить с записью B, и так далее. Это предотвращает взлом нескольких паролей одной попыткой, при условии, что повторное использование соли исключено. Соли также противодействуют использованию предварительно вычисленных таблиц для взлома паролей. Такая таблица может просто сопоставлять распространённые пароли с их хэшами, или выполнять более сложные операции, например, хранить начальные и конечные точки набора предварительно вычисленных хэш-цепочек. В любом случае, использование соли может защитить от предварительно вычисленных таблиц, увеличивая длину хэшей и используя более широкий набор символов, что снижает вероятность того, что таблица охватит полученные хэши. В частности, предварительно вычисленной таблице потребуется охватывать строку `attempt` || salt, а не просто `attempt`.
Современная система теневых паролей, в которой хэши паролей и другие данные безопасности хранятся в непубличном файле, несколько смягчает эти опасения. Однако они остаются актуальными в многосерверных установках, использующих централизованные системы управления паролями для передачи паролей или хэшей паролей на несколько систем. В таких установках учётная запись root на каждой отдельной системе может считаться менее надежной, чем администраторы централизованной системы паролей, поэтому важно обеспечить адекватную безопасность алгоритма хеширования паролей, включая генерацию уникальных значений соли. Другое (менее значительное) преимущество соли заключается в следующем: два пользователя могут выбрать одну и ту же строку в качестве пароля. Без соли этот пароль будет храниться в файле паролей как одна и та же хэш-строка. Это раскроет тот факт, что у двух учётных записей один и тот же пароль, что позволит любому, кто знает пароль одной учётной записи, получить доступ к другой. Используя соль, состоящую из двух случайных символов, даже если две учётные записи используют один и тот же пароль, никто не сможет это обнаружить, просто просмотрев хэши. Соль также значительно затрудняет определение того, использовал ли человек один и тот же пароль для нескольких систем.
1970-е - 1980-е годы
В более ранних версиях Unix использовался файл паролей /etc/passwd для хранения хэшей паролей с солью (паролей, к которым добавлены двухсимвольные случайные соли). В этих старых версиях Unix соль также хранилась в файле passwd (в открытом виде) вместе с хэшем пароля с солью. Файл паролей был доступен для чтения всем пользователям системы. Это было необходимо для того, чтобы привилегированные пользовательские инструменты могли находить имена пользователей и другую информацию. Таким образом, безопасность паролей обеспечивалась исключительно односторонними функциями (шифрованием или хэшированием), используемыми для этой цели. Ранние реализации Unix ограничивали длину паролей восемью символами и использовали 12-битную соль, что позволяло иметь 4096 возможных значений соли. Это было разумным компромиссом, учитывая вычислительные и затраты на хранение данных в 1970-х годах.
1980-е годы - настоящее время
Система теневых паролей используется для ограничения доступа к хешам и солям. Соль состоит из восьми символов, хеш – из 86 символов, а длина пароля практически неограничена, за исключением ошибок переполнения стека.
Реализация веб-приложений
Для веб-приложения обычно хранят в базе данных хеш пароля пользователя. Без использования соли успешная SQL-инъекция может привести к получению легко взламываемых паролей. Поскольку многие пользователи используют один и тот же пароль на разных сайтах, применение соли является важной составляющей общей безопасности веб-приложения. Дополнительные материалы по использованию соли для защиты хешей паролей в конкретных языках программирования или библиотеках (например, PHP, .NET) можно найти в разделе внешних ссылок ниже.