Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

Перец выполняет сравнимую роль с солью или ключом шифрования , но хотя соль не является секретной (просто уникальной) и может храниться вместе с хешированным выводом, перец является секретным и не должен храниться вместе с выводом. Хэш и соль обычно хранятся в базе данных, но перец должен храниться отдельно, чтобы предотвратить его получение злоумышленником в случае взлома базы данных. [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 итераций с использованием секретной соли вместо несекретной соли.

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

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

Случайно выбранный перец [ править ]

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

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

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

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

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