Соль (криптография)

В криптографии соль — это случайные данные, подаваемые в качестве дополнительных входных данных в одностороннюю функцию , которая хеширует данные , пароль или парольную фразу . ^[1] Соление помогает защититься от атак, использующих предварительно вычисленные таблицы (например, радужные таблицы ), значительно увеличивая размер таблицы, необходимый для успешной атаки. ^[2]^[3]^[4] Это также помогает защитить пароли, которые встречаются в базе данных несколько раз, поскольку для каждого экземпляра пароля используется новая соль. ^[5] Кроме того, засолка не накладывает никакой нагрузки на пользователей.

Обычно соль создается следующим образом: для каждого пароля случайным образом генерируется новая соль. Соль и пароль (или его версия после растяжения ключа ) объединяются и передаются в криптографическую хеш-функцию , а выходное хеш-значение затем сохраняется вместе с солью в базе данных. Соль не нужно шифровать, поскольку знание соли не поможет злоумышленнику. ^[5]

Соление широко используется в кибербезопасности, от Unix учетных данных системы до интернет-безопасности .

Соли связаны с криптографическими одноразовыми номерами .

Пример [ править ]

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

Имя пользователя	Строка для хеширования	Хэшированное значение = SHA256
`user1`	`password123`	`EF92B778BAFE771E89245B89ECBC08A44A4E166C06659911881F383D4473E94F`
`user2`	`password123`	`EF92B778BAFE771E89245B89ECBC08A44A4E166C06659911881F383D4473E94F`

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

Имя пользователя	Значение соли	Строка для хеширования	Хэшированное значение = SHA256 (пароль + значение соли)
`user1`	`D;%yL9TS:5PalS/d`	`password123D;%yL9TS:5PalS/d`	`9C9B913EB1B6254F4737CE947EFD16F16E916F9D6EE5C1102A2002E48D4C88BD`
`user2`	`)<,-<U(jLezy4j>*`	`password123)<,-<U(jLezy4j>*`	`6058B4EB46BD6487298B59440EC8E70EAE482239FF2B4E7CA69950DFBD5532F2`

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

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

Типичные ошибки [ править ]

Повторное использование соли [ править ]

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

Создание предварительно вычисленных таблиц для баз данных с уникальными солями для каждого пароля нецелесообразно из-за больших вычислительных затрат. Но если для всех записей используется общая соль, создание такой таблицы (которая учитывает соль) становится жизнеспособной и, возможно, успешной атакой. ^[6]

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

Длина соли [ править ]

Если соль слишком коротка, злоумышленник может заранее вычислить таблицу всех возможных солей, добавленных к каждому вероятному паролю. Использование длинной соли гарантирует, что такая таблица будет непомерно большой. ^[7]^[8]

Преимущества [ править ]

Чтобы понять разницу между взломом одного пароля и их набора, рассмотрим файл с пользователями и их хешированными паролями. Скажем, файл несоленый. Тогда злоумышленник сможет выбрать строку и вызвать ее 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]

Salts также борется с использованием предварительно вычисленных таблиц для взлома паролей. ^[10] Такая таблица может просто сопоставлять общие пароли с их хэшами или выполнять что-то более сложное, например хранить начальную и конечную точки набора предварительно вычисленных хеш-цепочек . В любом случае соль может защитить от использования предварительно вычисленных таблиц за счет удлинения хэшей и их извлечения из более крупных наборов символов, что снижает вероятность того, что таблица покроет полученные хэши. В частности, предварительно вычисленная таблица должна будет охватывать строку [salt + hash] а не просто [hash].

Современная система теневых паролей , в которой хэши паролей и другие данные безопасности хранятся в закрытом файле, несколько смягчает эти проблемы. Однако они остаются актуальными в многосерверных установках, в которых используются централизованные системы управления паролями для передачи паролей или хэшей паролей в несколько систем. В таких установках учетная запись root в каждой отдельной системе может рассматриваться как менее доверенная, чем учетная запись администраторов централизованной системы паролей, поэтому по-прежнему имеет смысл убедиться в том, что безопасность алгоритма хеширования паролей, включая генерацию уникальных значений соли, на уровне. адекватный. ^{[ нужна ссылка ]}

Другое (меньшее) преимущество соли заключается в следующем: два пользователя могут выбрать одну и ту же строку в качестве своего пароля. Без соли этот пароль будет храниться в виде той же хэш-строки в файле паролей. Это раскроет тот факт, что две учетные записи имеют один и тот же пароль, что позволит любому, кто знает пароли одной учетной записи, получить доступ к другой учетной записи. Если добавить в пароли два случайных символа, даже если две учетные записи используют один и тот же пароль, никто не сможет обнаружить это, просто прочитав хэши. Использование соли также чрезвычайно затрудняет определение того, использовал ли человек один и тот же пароль для нескольких систем. ^[11]

Реализации Unix [ править ]

1970–1980-е годы [ править ]

Более ранние версии Unix использовали файл паролей. /etc/passwd для хранения хешей соленых паролей (пароли с префиксом двухсимвольных случайных солей). В этих старых версиях Unix соль также хранилась в файле passwd (в виде открытого текста) вместе с хешем добавленного пароля. Файл паролей был доступен для чтения всем пользователям системы. Это было необходимо для того, чтобы программные инструменты с привилегиями пользователя могли находить имена пользователей и другую информацию. Таким образом, безопасность паролей обеспечивается только односторонними функциями (шифрованием или хешированием), используемыми для этой цели. Ранние реализации Unix ограничивали пароли восемью символами и использовали 12-битную соль, что позволяло использовать 4096 возможных значений соли. ^[12] Это был подходящий баланс для затрат на вычисления и хранение данных 1970-х годов. ^[13]

1980-е – настоящее время [ править ]

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

Реализации веб-приложений [ править ]

Обычно веб-приложение хранит в базе данных хэш-значение пароля пользователя. Без соли успешная атака с помощью SQL-инъекции может привести к получению легко взломанных паролей. Поскольку многие пользователи повторно используют пароли для нескольких сайтов, использование соли является важным компонентом общей безопасности веб-приложений . ^[14] Некоторые дополнительные ссылки по использованию соли для защиты хэшей паролей на определенных языках или библиотеках (PHP, библиотеки .NET и т. д.) можно найти в разделе внешних ссылок ниже.

См. также [ править ]

Ссылки [ править ]

^ Фентон, Джеймс Л.; Грасси, Пол А.; Гарсия, Майкл Э. (июнь 2017 г.). «Специальная публикация NIST 800-63-3» (PDF) . Публикации технической серии NIST .
^ Андерсон, Росс (2020). Инженерия безопасности: руководство по построению надежных распределенных систем (Третье изд.). Индианаполис, Индиана. ISBN 978-1-119-64281-7 . OCLC 1224516855 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
^ Годвин, Энтони (10 сентября 2021 г.). «Пароли имеют значение» . Заклинатель ошибок (блог) . Проверено 9 декабря 2016 г.
^ Боне, Дэн; Шуп, Виктор (4 января 2020 г.). Высший курс прикладной криптографии (PDF) . стр. 693–695.
^ Jump up to: Перейти обратно: ^а ^б Росулек, Майк (3 января 2021 г.). «Глава 11: Хэш-функции» (PDF) . Радость криптографии . стр. 204–205.
^ «Безопасное хеширование соленых паролей — как это сделать правильно» . https://crackstation.net . Проверено 19 марта 2021 г.
^ Менезес, Альфред Дж.; Ооршот, Пол К. ван; Ванстон, Скотт А. (1997). Справочник по прикладной криптографии . ЦРК Пресс. п. 288. ИСБН 0-8493-8523-7 .
^ «Безопасное хеширование соленых паролей — как это сделать правильно» .
^ «Хранение паролей — серия шпаргалок OWASP» . cheatsheetseries.owasp.org . Проверено 19 марта 2021 г.
^ «Как работают радужные таблицы» . kestas.kuliukas.com .
^ Столлингс, Уильям; Лори Браун (2015). Компьютерная безопасность: принципы и практика (Третье изд.). Бостон. ISBN 978-0-13-377392-7 . OCLC 874734678 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
^ Моррис, Роберт; Томпсон, Кен (3 апреля 1978 г.). «Безопасность паролем: история болезни» . Лаборатории Белла . Архивировано из оригинала 21 августа 2013 г.
^ Симсон Гарфинкель; Джин Спаффорд; Алан Шварц (2003). «Как Unix реализует пароли» . Практическая UNIX и интернет-безопасность (3-е изд.). О'Рейли Медиа. ISBN 9780596003234 .
^ «Дневник ISC — хеширование паролей» . Dshield.org . Проверено 15 октября 2011 г.

Внешние ссылки [ править ]

Вилле, Кристоф (5 января 2004 г.). «Хранение паролей – сделано правильно!» .
Криптографическая шпаргалка OWASP
как шифровать пароли пользователей

[1] Фентон, Джеймс Л.; Грасси, Пол А.; Гарсия, Майкл Э. (июнь 2017 г.). «Специальная публикация NIST 800-63-3» (PDF) . Публикации технической серии NIST .

[2] Андерсон, Росс (2020). Инженерия безопасности: руководство по построению надежных распределенных систем (Третье изд.). Индианаполис, Индиана. ISBN 978-1-119-64281-7 . OCLC 1224516855 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )

[3] Годвин, Энтони (10 сентября 2021 г.). «Пароли имеют значение» . Заклинатель ошибок (блог) . Проверено 9 декабря 2016 г.

[4] Боне, Дэн; Шуп, Виктор (4 января 2020 г.). Высший курс прикладной криптографии (PDF) . стр. 693–695.

[:0-5] Jump up to: Перейти обратно: ^а ^б Росулек, Майк (3 января 2021 г.). «Глава 11: Хэш-функции» (PDF) . Радость криптографии . стр. 204–205.

[6] «Безопасное хеширование соленых паролей — как это сделать правильно» . https://crackstation.net . Проверено 19 марта 2021 г.

[7] Менезес, Альфред Дж.; Ооршот, Пол К. ван; Ванстон, Скотт А. (1997). Справочник по прикладной криптографии . ЦРК Пресс. п. 288. ИСБН 0-8493-8523-7 .

[superidolsalts_.net-8] «Безопасное хеширование соленых паролей — как это сделать правильно» .

[9] «Хранение паролей — серия шпаргалок OWASP» . cheatsheetseries.owasp.org . Проверено 19 марта 2021 г.

[10] «Как работают радужные таблицы» . kestas.kuliukas.com .

[11] Столлингс, Уильям; Лори Браун (2015). Компьютерная безопасность: принципы и практика (Третье изд.). Бостон. ISBN 978-0-13-377392-7 . OCLC 874734678 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )

[12] Моррис, Роберт; Томпсон, Кен (3 апреля 1978 г.). «Безопасность паролем: история болезни» . Лаборатории Белла . Архивировано из оригинала 21 августа 2013 г.

[13] Симсон Гарфинкель; Джин Спаффорд; Алан Шварц (2003). «Как Unix реализует пароли» . Практическая UNIX и интернет-безопасность (3-е изд.). О'Рейли Медиа. ISBN 9780596003234 .

[14] «Дневник ISC — хеширование паролей» . Dshield.org . Проверено 15 октября 2011 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]