Войти
В криптографии соль является случайным данные, которые используются в качестве дополнительных входных данных для односторонней функции, которая хеширует данные, пароль или кодовую фразу. Соли используются для защиты паролей при хранении. Исторически пароль хранился в системе в виде открытого текста, но со временем были разработаны дополнительные меры безопасности для защиты пароля пользователя от чтения из системы. Соль - один из таких методов.
Для каждого пароля случайным образом генерируется новая соль. В типичных настройках соль и пароль (или его версия после растягивания ключа ) объединяются и обрабатываются с помощью криптографической хеш-функции , а выходной хэш значение (но не исходный пароль) сохраняется вместе с солью в базе данных. Хеширование позволяет проводить аутентификацию позже без сохранения и, следовательно, риска раскрытия пароля в виде обычного текста в случае взлома хранилища данных аутентификации.
Соли защищают от заранее вычисленной хеш-атаки, например радужные таблицы. Поскольку люди не должны запоминать соли, они могут сделать размер хеш-таблицы, требуемый для успешной атаки, чрезмерно большим, не обременяя пользователей. Поскольку соли в каждом случае различны, они также защищают часто используемые пароли или тех пользователей, которые используют один и тот же пароль на нескольких сайтах, делая все экземпляры соленого хэша для одного и того же пароля разными друг от друга.
Криптографические соли широко используются во многих современных компьютерных системах, от учетных данных системы Unix до Интернет-безопасности.
Соли тесно связаны с концепцией криптографического одноразового кода ..
Вот неполный пример значения соли для хранения паролей.. В этой первой таблице есть две комбинации имени пользователя и пароля. Пароль не сохраняется.
| Имя пользователя | Пароль |
|---|---|
| user1 | password123 |
| user2 | password123 |
Значение соли генерируется случайным образом и может быть любой длины, в этом случае значение соли Длина 16 байт. Значение соли добавляется к паролю в виде открытого текста, а затем результат хешируется, это называется хешированным значением. Сохраняются как значение соли, так и хеш-значение.
| Имя пользователя | Значение соли | Строка для хеширования | Хешированное значение = SHA256 (Пароль + значение соли) |
|---|---|---|---|
| user1 | E1F53135E559C253 | password123 E1F53135E559C253 | 72AE25495A7981C40622D49F9A52E4F1565C90F048F59027BD9C8C8900D5C3D8 |
| пользователь2 | 84B03D034B409D4E | password123 84B03D034B409D4E | B4B6603ABC670967E99C7E7F1389E40CD16E78AD38EB1468EC2AA1E62B8BED3A |
Как и выше таблица иллюстрирует различные значения соль будет создавать совершенно разные хешированные значения, даже если пароли в виде открытого текста точно такие же. Кроме того, словарные атаки смягчаются до некоторой степени, поскольку злоумышленник не может практически предварительно вычислить хэши. Однако соль не может защитить обычные или легко угадываемые пароли.
Фиксированная соль - это когда программист использует одну и ту же соль для каждого хешированного пароля.
Хотя это сделает текущие радужные таблицы бесполезными (если соль выбрана правильно), если соль жестко запрограммирована в популярный продукт, соль может быть извлечена и новая радужная таблица могут быть созданы с использованием этой соли.
Использование единственной фиксированной соли также означает, что каждый пользователь, вводящий один и тот же пароль, будет иметь один и тот же хэш (если только хеш пароля не зависит от имени пользователя). Это упрощает атаку нескольких пользователей путем взлома только одного хеша.
Если соль слишком короткая, злоумышленнику будет легко создать радужную таблицу, состоящую из всех возможных солей, добавленных к каждому вероятному паролю. Использование длинной соли гарантирует, что радужная таблица для базы данных будет чрезмерно большой.
Чтобы понять разницу между взломом одного пароля и их набора, рассмотрим один файл паролей. который содержит сотни имен пользователей и хешированных паролей. Без соли злоумышленник может вычислить хэш (попытка [0]), а затем проверить, появляется ли этот хеш где-нибудь в файле. Вероятность совпадения, то есть взлома одного из паролей с помощью этой попытки, увеличивается с увеличением количества паролей в файле. Если соли присутствуют, злоумышленник должен будет вычислить хэш (соль [a], попытка [0]), сравнить с записью A, затем хэш (соль [b], попытка [0]), сравнить с записью B и скоро. Это предотвращает «повторное использование» хэшей при попытках взлома нескольких паролей.
Salts также борются с использованием хеш-таблиц и радужных таблиц для взлома паролей. Хеш-таблица - это большой список предварительно вычисленных хешей для часто используемых паролей. Для файла паролей без солей злоумышленник может просмотреть каждую запись и найти хешированный пароль в хэш-таблице или радужной таблице. Если поиск выполняется значительно быстрее, чем хэш-функция (что часто бывает), это значительно ускорит взлом файла. Однако, если файл паролей соленый, то хеш-таблица или радужная таблица должна содержать предварительно хешированный «соль. Пароль». Если соль достаточно длинная и достаточно случайная, это маловероятно. Пароли без соли, выбранные людьми, обычно уязвимы для словарных атак, поскольку они должны быть как короткими, так и достаточно значимыми, чтобы их можно было запомнить. Даже небольшой словарь (или его хешированный эквивалент, хеш-таблица) значительно помогает взломать наиболее часто используемые пароли. Поскольку людям не нужно запоминать соли, они могут сделать размер радужной таблицы, необходимой для успешной атаки, чрезмерно большим, не обременяя пользователей.
С технической точки зрения соли защищают от хэш-таблиц и радужных таблиц, поскольку они, по сути, увеличивают длину и, возможно, сложность пароля. Если в радужных таблицах нет паролей, соответствующих длине (например, 8-байтовый пароль и 2-байтовая соль, фактически является 10-байтовым паролем) и сложностью (не буквенно-цифровая соль увеличивает сложность строго буквенно-цифровых паролей) соленый пароль, то пароль не будет найден. В случае обнаружения необходимо удалить соль из пароля, прежде чем его можно будет использовать.
Современная система теневых паролей, в которой хэши паролей и другие данные безопасности хранятся в закрытом файле, несколько смягчает эти проблемы. Однако они остаются актуальными в многосерверных установках, в которых используются централизованные системы управления паролями для передачи паролей или хэшей паролей в несколько систем. В таких установках учетная запись root в каждой отдельной системе может рассматриваться как менее надежная, чем администраторы централизованной системы паролей, поэтому по-прежнему целесообразно обеспечить безопасность алгоритма хеширования паролей, включая создание уникальных значений соли, достаточно.
Соли также делают атаки по словарю и атаки грубой силы для взлома большого количества паролей намного медленнее (но не в этом случае взлома только одного пароля). Без солей злоумышленнику, который взламывает множество паролей одновременно, нужно только один раз хешировать каждое предположение пароля и сравнивать его со всеми хэшами. Однако с солями каждый пароль, скорее всего, будет иметь разную соль; поэтому каждое предположение нужно будет хешировать отдельно и сравнивать для каждой соли, что значительно медленнее, чем сравнение одного и того же хеша с каждым паролем.
Еще одно (меньшее) преимущество соли заключается в следующем: два пользователя могут выбрать одну и ту же строку в качестве своего пароля, или один и тот же пользователь может использовать один и тот же пароль на двух машинах. Без соли этот пароль будет храниться в той же строке хеша в файле паролей. Это раскрыло бы тот факт, что две учетные записи имеют один и тот же пароль, что позволит любому, кто знает один из паролей учетной записи, получить доступ к другой учетной записи. Добавляя в пароли два случайных символа, даже если две учетные записи используют один и тот же пароль, никто не может обнаружить это, просто прочитав хэши.
Более ранние версии Unix использовали файл паролей / etc / passwdдля хранения хэшей паролей с солью (пароли с префиксом из двух символов случайной соли). В этих более старых версиях Unix соль также хранилась в файле passwd (в виде открытого текста) вместе с хешем пароля с солью. Файл паролей был доступен для чтения всем пользователям системы. Это было необходимо для того, чтобы программные инструменты с привилегиями пользователя могли находить имена пользователей и другую информацию. Поэтому безопасность паролей защищена только односторонними функциями (шифрование или хеширование), используемыми для этой цели. Ранние реализации Unix ограничивали пароли до восьми символов и использовали 12-битную соль, что позволяло использовать 4096 возможных значений соли. Это было подходящим балансом для затрат 1970-х на вычисления и хранение.
Система теневых паролей используется для ограничения доступа к хешам и соли. Соль составляет восемь символов, хеш - 86 символов, а длина пароля не ограничена.
Обычно веб-приложение хранит в базе данных хеш-значение пароля пользователя. Без соли успешная атака SQL-инъекцией может дать легко взломанные пароли. Поскольку многие пользователи повторно используют пароли для нескольких сайтов, использование соли является важным компонентом общей безопасности веб-приложений. Некоторые дополнительные ссылки на использование соли для защиты хэшей паролей на определенных языках (PHP,.NET и т. Д.) Можно найти в разделе внешних ссылок ниже.
