Можно ли выяснить ключ из оригинала и зашифрованной строки?

Question

Редактировать

Я сталкиваюсь с этим, так как у меня до сих пор нет окончательного ответа (хотя один или два близки). В основном я ищу ответ yes или no с некоторой информацией для его подтверждения.

---

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

Правильный способ, которым мы теперь знаем (в соответствии с большинством (?)), Заключается в хранении соленого хэша PW в БД, но, будучи относительно близким к выпуску, мы хотели бы минимизировать изменение кода и, следовательно, считалось, что очень простой способ не допустить, чтобы кто-то считывал PW из БД, состояло бы в простом изменении процесса и переключении параметров.

Таким образом, мы зашифруем уникальную подсоленную строку для каждой системы (сотни из них) (с произвольным хвостом, добавленным для каждого шифрования), используя пароль пользователя в качестве ключа, сохраняя результат в БД. При проверке PW мы расшифруем строку, сохраненную в БД, с введенным PW и сопоставим с системным ключом для проверки.

System key+random шифровать с password хранить в БД encrypted key.

т.е. пароли пользователей никогда не хранятся, и в нашем простом сознании они необратимы.

Но, будучи новичками в секторе шифрования, мы задаемся вопросом, может ли кто-нибудь с большим опытом в этой области ответить на простой вопрос -

Можно ли определить ключ по оригиналу и зашифрованной строке?

Мы думаем, что это блестящий ;) способ гарантировать, что пароли пользователей не будут скомпрометированы, но мы не можем найти ничего о методе онлайн. Это делает нас неуверенными в этом, поэтому мы просим об этом великое сообщество.

(И Грубая сила не является адекватным ответом, поскольку от этого (при данных обстоятельствах) невозможно защититься.)

Редактировать:

Я вставлю один из моих комментариев сюда (надеюсь), чтобы кое-что прояснить:

---

@ zaph Спасибо за ваш вклад, но я думаю, что большинство здесь упускают суть. Через несколько дней у нас будет замораживание кода для следующего выпуска, и я уже реализовал метод, о котором упоминал в этом вопросе. До следующего выпуска я прочитаю эту тему и реализую стороннюю библиотеку, такую ​​как scrypt или аналогичную. Мне просто нужно знать, существуют ли существующие жизнеспособные алгоритмы для обратного процесса и, следовательно, сделать мою новую реализацию хуже, чем старый подход с шифрованным паролем.

Answer 1

Из быстрого гугла я нашел эту тему обмена стека .

Попытка выяснить ключ на основе открытого текста и зашифрованного текста называется Атака известного открытого текста . Большинство алгоритмов шифрования не подвержены этой атаке.

Answer 2

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

Прежде всего, я не увидел здесь никакой ссылки на OWASP . Вероятно, они являются крупнейшим сообществом по безопасности программного обеспечения, и вы всегда должны проверять их рекомендации не только для защиты паролем, но и для любых других вопросов безопасности. Каждый год они выпускают документ под названием « OWASP Top 10 », в котором перечислены наиболее распространенные уязвимости веб-приложений.

Исходя из прошлогодней OWASP Top 10 , риск, который вы пытаетесь снизить, - это номер №3 в списке, который называется « Обнаружение конфиденциальных данных ». Это относится не только к паролям, но и к таким конфиденциальным данным, как, например, номер кредитной карты. Для проблемы, описанной в вашем вопросе, я хотел бы выделить третий пример сценария атаки:

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

Чтобы предотвратить такую ​​атаку (иногда называемую «радугой»), вот рекомендации OWASP:

1. Классифицировать данные, обрабатываемые, хранящиеся или передаваемые приложением. Определите, какие данные являются конфиденциальными в соответствии с законами о конфиденциальности, регулирующими требования или бизнес-потребности.
2. Применить средства управления в соответствии с классификацией.
3. Не храните конфиденциальные данные без необходимости. Откажитесь от него как можно скорее или используйте токены, совместимые с PCI DSS, или даже усечения. Данные, которые не были сохранены, не могут быть украдены.
4. Обязательно шифруйте все конфиденциальные данные в состоянии покоя.
5. Обеспечить наличие современных и надежных стандартных алгоритмов, протоколов и ключей; используйте правильное управление ключами.
6. Шифрование всех передаваемых данных с помощью безопасных протоколов, таких как TLS, с использованием шифров с совершенной прямой секретностью (PFS), приоритезация шифров сервер и параметры безопасности. Обеспечить шифрование с использованием директив как HTTP Strict Transport Security ( HSTS ).
7. Отключить кэширование для ответов, содержащих конфиденциальные данные.
8. Храните пароли, используя мощные адаптивные и соленые функции хеширования с рабочим коэффициентом (коэффициент задержки), такие как Argon2 , scrypt , bcrypt или PBKDF2 .
9. Проверьте самостоятельно эффективность конфигурации и настроек.

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

Кроме того, не забывайте периодически запускать тесты на проникновение (ручные тесты) в вашей производственной среде. Это ОЧЕНЬ важно.

Если вы хотите начать тестирование / проверку вашей защиты от радужной атаки, OWASP предоставляет инструмент под названием " OWASP Rainbow Maker ".

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

Надеюсь, это поможет, и если у вас есть какие-либо вопросы, стреляйте в комментарии.

Answer 3

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

В качестве стандартного метода безопасности пароли НИКОГДА не должны извлекаться из базы данных , либо с помощью мастер-ключа или метода восстановления пароля . Если злоумышленник получит доступ к источнику приложения или базе данных, ему все равно будет трудно украсть личность пользователя, поскольку он не сможет получить пароль пользователя.

Таким образом, ваш подход может использовать ваш per system (hundreds of them) unique salted string (with a per encryption added random tail) для каждого пользователя, сохранять его в базе данных и использовать ввод пароля пользователя в качестве хеш-соли (вместо ключа, как вы предлагали). Разница между этим методом и вашим заключается в том, что вы не будете расшифровывать сохраненный хеш, но вместо этого будете сравнивать хэш, сгенерированный пользовательским вводом, с сохраненным хешем.

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

Answer 4

По запросу: «ответ на вопрос из достоверных и / или официальных источников» - Национальный институт стандартов и технологий.

NIST Руководство по цифровой идентификации стр. 15: … Верификаторы ДОЛЖНЫ хранить запомненные секреты в форме, устойчивой к атакам в автономном режиме. Запомненные секреты ДОЛЖНЫ быть засолены и хешированы с использованием подходящей односторонней функции получения ключей. Функции вывода ключей принимают пароль, соль и коэффициент стоимости в качестве входных данных, а затем генерируют хэш пароля.

Соль должна быть криптографически безопасной и уникальной для каждого пароля, она может - и обычно - сохраняется с хешированным паролем. Коэффициент стоимости должен находиться в диапазоне 1us времени ЦП (не прошедшего). Коэффициент стоимости также может быть сохранен с паролем и, следовательно, может быть обновлен в будущем по мере необходимости.

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

Другие функции с похожими свойствами включают PBKDF2, Rfc2898DeriveBytes, Argon2i, password_hash, Bcrypt.

Примечания (перенесено из комментариев к вопросу):

В ответ на: А грубая сила не является адекватным ответом, поскольку от этого (при данных обстоятельствах) невозможно защититься.
Это именно тот тип атаки, от которого нужно и можно защитить. В настоящее время наилучшей практикой является требование, чтобы каждая попытка была уникальной и занимала много времени. Таким образом, случайная соль и итерация ~ 100 мс. Таким образом, каждая попытка пробного пароля против хешированного пользователем пароля требует значительного времени. Атака для продажи в Dark Web требует большого количества учетных данных пользователя, поэтому большинство паролей должно быть взломано, чтобы быть прибыльным.

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

Потенциальная атака против предложенного решения ОП:
Ранее я публиковал возможную и простую атаку, вот она снова: получите БД и системный ключ для проверки. Выберите запись из списка частых паролей и попробуйте ввести системный ключ. Это очень быстро, меньше микросекунды, поэтому большинство паролей будет найдено быстро. При обычной атаке не нужно находить все пароли, достаточно большого процента, чтобы пользовательская информация + пароль продавались в Dark Web .

Answer 5

Извините, но следуйте тому, что делает большинство людей, и хэшируйте пароли солью, используя что-то вроде bcrypt или scrypt. Попробуйте использовать известную, популярную библиотеку, чтобы сделать вещи быстрее и проще (прокомментируйте, если вам нужна помощь в поиске).

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

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

Answer 6

Я думаю, что gusto2 - это немного OTT, хотя, хотя это лучше, чем решение с мастер-паролем, которое вы пытаетесь заменить, оно все еще далеко от приемлемого.

Более или менее как crypt работает в режиме DES . Однако в вашей реализации, которая не использует уникальную соль для каждого пользователя, будет очевидно, когда 2 пользователя имеют один и тот же пароль (переключение обратимого шифрования для хэша ничего не делает для смягчения этого). Возможно, вы используете лучший алгоритм с большим количеством битов, но ваша реализация отстает от 40-летней технологии.

Answer 7

У нас есть система, хранящая пароли пользователей, зашифрованные общим системным ключом в базе данных.

Это ОЧЕНЬ плохая практика, поскольку пароль потенциально обратим. По моему опыту - утечка данных - это только вопрос времени, и ... ваш потенциально катастрофический сценарий сбудется.

Правильный способ, которым мы теперь знаем (согласно большинству (?)), Состоит в том, чтобы хранить соленый хэш PW в БД,

Наилучшим вариантом сегодня является использование "медленного хеширования", см. https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846

При проверке PW мы расшифруем строку, сохраненную в БД, с введенным PW и сопоставим с системным ключом для проверки.

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

Можно ли определить ключ по оригиналу и зашифрованной строке?

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