В криптографии , А соль представляет случайные данные, используемые в качестве дополнительного входа к односторонней функции , что хэши данные , A пароль или ключевая фраза . [1] Соли используются для защиты паролей в хранилище. Исторически в системе хранилась только криптографическая хеш-функция пароля, но со временем были разработаны дополнительные меры безопасности для защиты от идентифицируемых повторяющихся или общих паролей (поскольку их хэши идентичны). [2] Соление - одна из таких мер защиты.
Для каждого пароля случайным образом генерируется новая соль. Обычно соль и пароль (или его версия после растяжения ключа ) объединяются и передаются в криптографическую хеш-функцию , а выходное хеш-значение (но не исходный пароль) сохраняется вместе с солью в базе данных. Хеширование позволяет проводить аутентификацию позже без сохранения и, следовательно, риска раскрытия пароля в виде открытого текста, если хранилище данных аутентификации будет скомпрометировано. Обратите внимание, что из-за этого соли не нужно шифровать или хранить отдельно от самого хешированного пароля, потому что даже если злоумышленник имеет доступ к базе данных с хеш-значениями и солями, правильное использование указанных солей будет препятствовать общему использованию. атаки. [1]
Соли защищают от атак, которые используют предварительно вычисленные таблицы (например, радужные таблицы ) [3], поскольку они могут сделать размер таблицы, необходимый для успешной атаки, чрезмерно большим, не обременяя пользователей. Поскольку соли отличаются друг от друга, они также защищают избыточные (например, часто используемые, повторно используемые) пароли, поскольку для разных экземпляров одного и того же пароля создаются разные хэши с солью.
Криптографические соли широко используются во многих современных компьютерных системах, от учетных данных системы Unix до безопасности в Интернете .
Соли тесно связаны с концепцией криптографического одноразового номера .
Пример использования
Вот неполный пример значения соли для хранения паролей. В этой первой таблице есть две комбинации имени пользователя и пароля. Пароль не сохраняется.
Имя пользователя | Пароль |
---|---|
user1 | пароль123 |
user2 | пароль123 |
Значение соли генерируется случайным образом и может иметь любую длину; в этом случае значение соли составляет 8 байтов . Значение соли добавляется к паролю в виде открытого текста, а затем результат хешируется, это называется хешированным значением. Сохраняются как значение соли, так и значение хеширования.
Имя пользователя | Солевое значение | Строка для хеширования | Хешированное значение = SHA256 (пароль + значение соли) |
---|---|---|---|
user1 | E1F53135E559C253 | password123 E1F53135E559C253 | 72AE25495A7981C40622D49F9A52E4F1565C90F048F59027BD9C8C8900D5C3D8 |
user2 | 84B03D034B409D4E | password123 84B03D034B409D4E | B4B6603ABC670967E99C7E7F1389E40CD16E78AD38EB1468EC2AA1E62B8BED3A |
Как показано в приведенной выше таблице, разные значения соли будут создавать совершенно разные хешированные значения, даже если пароли в виде открытого текста совершенно одинаковы. Кроме того, словарные атаки в некоторой степени смягчаются, поскольку злоумышленник не может практически предварительно вычислить хэши . Однако соль не может защитить обычные или легко угадываемые пароли.
Распространенные ошибки
Повторное использование соли
Использование одной и той же соли для всех паролей опасно, потому что предварительно вычисленная таблица, которая просто учитывает соль, сделает соль бесполезной.
Создание предварительно вычисленных таблиц для баз данных с уникальными солями для каждого пароля нецелесообразно из-за вычислительных затрат на это. Но если для всех записей используется обычная соль, создание такой таблицы (которая учитывает соль) становится жизнеспособной и, возможно, успешной атакой. [4]
Поскольку повторное использование соли может привести к тому, что пользователи с одним и тем же паролем будут иметь один и тот же хеш, взлом одного хеша может привести к взлому и других паролей.
Короткая соль
Если соль слишком короткая, злоумышленник может предварительно вычислить таблицу всех возможных солей, добавленную к каждому вероятному паролю. Использование длинной соли гарантирует, что такой стол будет чрезмерно большим. [5]
Преимущества
Чтобы понять разницу между взломом одного пароля и их набора, рассмотрим файл с пользователями и их хешированными паролями. Скажем, файл несоленый. Затем злоумышленник может выбрать строку, назвать ее попыткой [0], а затем вычислить хэш (попытка [0]). Пользователь, чей хэш хранится в файле, является хешем (попытка [0]), может иметь или не иметь попытки ввода пароля [0]. Однако, даже если попытка [0] не является фактическим паролем пользователя, она будет принята, как если бы это было так, потому что система может проверять пароли, только вычисляя хэш введенного пароля и сравнивая его с хешем, хранящимся в файле. Таким образом, при каждом совпадении пароль пользователя взламывается, и вероятность совпадения возрастает с увеличением количества паролей в файле. Напротив, если используются соли, злоумышленник должен будет вычислить хэш (попытка [0] || salt [a]), сравнить с записью A, затем хеш (попытка [0] || salt [b]), сравнить с запись B и т. д. Это предотвращает одну попытку взлома нескольких паролей (только если исключено повторное использование соли). [6]
Соли также борются с использованием предварительно вычисленных таблиц для взлома паролей. [7] Такая таблица может просто сопоставлять общие пароли с их хэшами или делать что-то более сложное, например хранить начальную и конечную точки набора предварительно вычисленных цепочек хешей . В любом случае использование солей может защитить от использования предварительно вычисленных таблиц, удлиняя хэши и заставляя их извлекать из более крупных наборов символов, что снижает вероятность того, что таблица покрывает результирующие хэши. В частности, предварительно вычисленная таблица должна охватывать строку [salt + hash], а не просто [hash].
Современная система теневых паролей , в которой хэши паролей и другие данные безопасности хранятся в закрытом файле, несколько смягчает эти проблемы. Однако они остаются актуальными в многосерверных установках, в которых используются централизованные системы управления паролями для передачи паролей или хэшей паролей в несколько систем. В таких установках учетная запись root в каждой отдельной системе может рассматриваться как менее доверенная, чем администраторы централизованной системы паролей, поэтому по-прежнему целесообразно обеспечить безопасность алгоритма хеширования паролей, включая создание уникальных значений соли. адекватный. [ необходима цитата ]
Другое (меньшее) преимущество соли заключается в следующем: два пользователя могут выбрать одну и ту же строку в качестве своего пароля или один и тот же пользователь может использовать один и тот же пароль на двух машинах. Без соли этот пароль будет храниться в той же строке хеша в файле паролей. Это раскрыло бы тот факт, что две учетные записи имеют одинаковый пароль, позволяя любому, кто знает один из паролей учетной записи, получить доступ к другой учетной записи. Добавляя в пароли два случайных символа, даже если две учетные записи используют один и тот же пароль, никто не может обнаружить это, просто прочитав хеши.
Реализации Unix
1970–1980 годы
Более ранние версии Unix использовали файл паролей /etc/passwd
для хранения хешей паролей с солью (паролей с префиксом из двух символов случайных солей). В этих более старых версиях Unix соль также хранилась в файле passwd (в виде открытого текста) вместе с хешем пароля с солью. Файл паролей был доступен для чтения всем пользователям системы. Это было необходимо для того, чтобы программные инструменты с привилегиями пользователя могли находить имена пользователей и другую информацию. Поэтому безопасность паролей защищена только односторонними функциями (шифрованием или хешированием), используемыми для этой цели. Ранние реализации Unix ограничивали пароли до восьми символов и использовали 12-битную соль, что позволяло использовать 4096 возможных значений соли. [8] Это был подходящий баланс для затрат 1970-х годов на вычисления и хранение. [9]
1980-е годы -
Система теневых паролей используется для ограничения доступа к хешам и соли. Соль составляет восемь символов, хеш - 86 символов, а длина пароля не ограничена.
Реализации веб-приложений
Обычно веб-приложение хранит в базе данных хеш-значение пароля пользователя. Без соли успешная атака с использованием SQL-инъекции может дать легко взломанные пароли. Поскольку многие пользователи повторно используют пароли для нескольких сайтов, использование соли является важным компонентом общей безопасности веб-приложений . [10] Некоторые дополнительные ссылки на использование соли для защиты хэшей паролей на определенных языках (PHP, .NET и т. Д.) Можно найти в разделе внешних ссылок ниже.
Смотрите также
Рекомендации
- ^ a b «Превышен предел загрузки» . citeseerx.ist.psu.edu . Проверено 14 мая 2021 .
- ^ Андерсон, Росс (2020). Инженерия безопасности: руководство по созданию надежных распределенных систем (Третье изд.). Индианаполис, Индиана. ISBN 978-1-119-64281-7. OCLC 1224516855 .
- ^ «Пароли имеют значение» . Проверено 9 декабря 2016 .
- ^ «Безопасное хеширование паролей - как это сделать правильно» . crackstation.net . Проверено 19 марта 2021 .
- ^ «Безопасное хеширование паролей - как это сделать правильно» .
- ^ «Хранение паролей - серия шпаргалок по OWASP» . cheatsheetseries.owasp.org . Проверено 19 марта 2021 .
- ^ «Как работают радужные таблицы» . kestas.kuliukas.com .
- ^ Моррис, Роберт; Томпсон, Кен (1978-04-03). «Защита паролем: история болезни» . Мюррей Хилл, Нью-Джерси, США: Bell Laboratories . Архивировано из оригинала на 2013-08-21. Цитировать журнал требует
|journal=
( помощь ) - ^ «Как Unix реализует пароли [Книга]» .
- ^ «Дневник ISC - Хеширование паролей» . Dshield.org . Проверено 15 октября 2011 .
Внешние ссылки
- Вилле, Кристоф (2004-01-05). «Хранение паролей - сделано правильно!» .
- Шпаргалка по криптографии OWASP
- как зашифровать пароли пользователей