it-swarm.com.ru

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

Правка  

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


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

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

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

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

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

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

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

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

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

Правка:  

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


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

8
SamWhan

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

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

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

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

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

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

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

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

6
gusto2

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

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

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

4
Innovative Inventor

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

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

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

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

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

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

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

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

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

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

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

2
Fabio Manzano

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

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

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

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

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

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

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

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

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

2
zaph

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

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

0
symcbean

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

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

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

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

0
Niche