Jump to content

Перец (криптография)

В криптографии перец это секрет, добавляемый к вводу, например паролю, во время хеширования с помощью криптографической хеш-функции . Это значение отличается от соли тем, что оно не хранится вместе с хешем пароля, а скорее хранится отдельно на каком-либо другом носителе, например, в аппаратном модуле безопасности. [1] Обратите внимание, что Национальный институт стандартов и технологий называет это значение секретным ключом, а не перцем . По своей концепции перец похож на соль или ключ шифрования . Это похоже на соль в том смысле, что это случайное значение, которое добавляется к хешу пароля, и оно похоже на ключ шифрования в том смысле, что его следует хранить в секрете.

Перец выполняет роль, сравнимую с солью или ключом шифрования , но хотя соль не является секретной (просто уникальной) и может храниться вместе с хешированными выходными данными, перец является секретным и не должен храниться вместе с выходными данными. Хэш и соль обычно хранятся в базе данных, но перец необходимо хранить отдельно, чтобы злоумышленник не смог получить его в случае взлома базы данных. [2] Где соль должна быть достаточно длинной, чтобы быть уникальной для каждого пользователя. [ сомнительно обсудить ] , перец должен быть достаточно длинным, чтобы оставаться в тайне от попыток его обнаружения методом грубой силы (NIST рекомендует не менее 112 бит).

История [ править ]

Идея использования соли для конкретного сайта или службы (в дополнение к соли для каждого пользователя) имеет долгую историю: Стивен М. Белловин предложил локальный параметр в сообщении Bugtraq в 1995 году. [3] В 1996 году Уди Манбер также описал преимущества такой схемы, назвав ее секретной солью . [4] Термин перец использовался по аналогии с солью, но в разных значениях. Например, при обсуждении схемы «запрос-ответ » перец использовался в качестве количества, подобного соли, но не использовался для хранения паролей; [5] он использовался для техники передачи данных, в которой нужно угадать перец; [6] и даже в рамках шуток. [7]

Термин «перец» был предложен для обозначения секретного или локального параметра, хранящегося отдельно от пароля, при обсуждении защиты паролей от атак радужных таблиц . [8] Такое использование не сразу прижилось: например, Фред Вензель добавил поддержку хеширования паролей Django для хранения на основе комбинации bcrypt и HMAC с отдельно хранящимися одноразовыми номерами , не используя этот термин. [9] С тех пор использование стало более распространенным. [10] [11] [12]

Типы [ править ]

Существует несколько видов перца:

  • Секрет, уникальный для каждого пользователя. [ нужна ссылка ]
  • Общий секрет, общий для всех пользователей. [2]
  • Случайно выбранное число, которое необходимо обнаруживать заново при каждом вводе пароля. [13]

Перец общего секрета [ править ]

В случае перца с общим секретом один скомпрометированный пароль (путем повторного использования пароля или другой атаки) вместе с солью пользователя может привести к атаке с целью обнаружения перца, что сделает ее неэффективной. Если злоумышленник знает пароль в виде открытого текста и соль пользователя, а также алгоритм, используемый для хеширования пароля, то обнаружение перца может быть вопросом грубого подбора значений перца. Вот почему NIST рекомендует, чтобы секретное значение составляло не менее 112 бит, чтобы его обнаружение путем полного поиска было затруднительным. Перчик должен создаваться заново для каждого приложения, в котором он развернут, иначе взлом одного приложения приведет к снижению безопасности другого приложения. Без знания перца другие пароли в базе данных будет гораздо сложнее извлечь из их хешированных значений, поскольку злоумышленнику придется угадать не только перец, но и пароль.

Перец повышает безопасность базы данных солей и хэшей, поскольку, если злоумышленник не сможет получить перец, взломать даже один хеш будет невозможно, независимо от того, насколько слабым является исходный пароль. Даже имея список пар (соль, хэш), злоумышленник также должен угадать секретный перец, чтобы найти пароль, который создает хэш. Спецификация NIST для секретной соли предлагает использовать функцию деривации ключей на основе пароля (PBKDF) с утвержденной псевдослучайной функцией, такой как HMAC с SHA-3, в качестве хеш-функции HMAC. Рекомендация NIST также заключается в выполнении не менее 1000 итераций PBKDF и еще минимум 1000 итераций с использованием секретной соли вместо несекретной соли.

Уникальный перец для каждого пользователя [ править ]

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

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

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

  1. ^ «Специальная публикация NIST 800-63B» . 16 декабря 2022 г. Раздел 5.1.1.2 . Проверено 10 октября 2023 г. ... верификаторы ДОЛЖНЫ выполнить дополнительную итерацию операции хеширования или шифрования с использованием секретного ключа, известного только верификатору.
  2. Перейти обратно: Перейти обратно: а б Ахаве, Девдатта. «Как Dropbox безопасно хранит ваши пароли» . dropbox.tech . Проверено 4 ноября 2020 г.
  3. ^ Белловин, Стив (16 апреля 1995 г.). «Алгоритм хеширования пароля» . секлисты . Проверено 11 ноября 2020 г.
  4. ^ Манбер, Уди (1996). «Простая схема, позволяющая сделать пароли, основанные на односторонних функциях, гораздо труднее взломать» . Компьютеры и безопасность . 15 (2): 171–176. дои : 10.1016/0167-4048(96)00003-x . Проверено 11 ноября 2020 г.
  5. ^ Блейк, Росс; Джексон, Коллин; Мияке, Ник; Боне, Дэн; Митчелл, Джон (2005). «Более надежная аутентификация пароля с помощью расширений браузера» . Симпозиум по безопасности USENIX : 17–32 . Проверено 11 ноября 2020 г.
  6. ^ Ларс Шенинг (25 января 2006 г.). «Передача данных только для хэша (Pepper)». Группа новостей : sci.crypt .
  7. ^ цирустевирус (7 июня 2007 г.). «Факты о Брюсе Шнайере». Группа новостей : it.test . Большинство людей солят свой гашиш. Брюс солит и перчит его.
  8. ^ Вебстер, Крейг (3 августа 2009 г.). «Защита паролей с помощью соли, перца и радуги» . Лающая игуана . Проверено 11 ноября 2020 г.
  9. ^ Венцель, Фред (12 марта 2011 г.). «История django-sha2/django_sha2/bcrypt_auth.py» . Гитхаб . Проверено 11 ноября 2020 г.
  10. ^ Патрик Милунд Нильсен (30 мая 2012 г.). «Генерация соли для шифрования с использованием golang» . голанг-орехи (список рассылки).
  11. ^ Дуонг, Тайланд (05.09.2020). «Почему вы хотите шифровать хэши паролей» . блог vnhacker . Проверено 11 ноября 2020 г.
  12. ^ @Sc00bzT (18 сентября 2020 г.). «Использование перца означает «некриптографическую соль» » ( Твит ) – через Twitter .
  13. ^ «Атака методом грубой силы на пароли UNIX с помощью SIMD-компьютера» (PDF) . Август 1999 года.

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

Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 4a20e55354f99790151f9d53fcf2fc7a__1696957080
URL1:https://arc.ask3.ru/arc/aa/4a/7a/4a20e55354f99790151f9d53fcf2fc7a.html
Заголовок, (Title) документа по адресу, URL1:
Pepper (cryptography) - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)