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

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

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

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

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

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

можно ли вычислить ключ из исходной и зашифрованной строки?

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

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

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

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

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

NIST Digital Identity Guidelines Страница 15: ... верификаторы должны хранить запомненные секреты в форме, устойчивой к атакам в автономном режиме. Запоминаемые секреты должны быть засолены и хэшированы с использованием подходящей односторонней функции вывода ключа. Ключевые функции деривации принимают пароль, соль и стоимость фактор в качестве входных данных затем сгенерировать хэш пароля.

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

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

другие функции с подобными свойствами относятся PBKDF2, Rfc2898DeriveBytes, Argon2i, password_hash, Bcrypt.

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

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

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

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

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

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

на основе прошлогоднего OWASP Top 10, риск, который вы пытаетесь смягчить, - это номер #3 в списке, называемый"Экспозиция Конфиденциальных Данных". Это относится не только к паролям, но и к конфиденциальным данным, таким как номер кредитной карты, например. Для проблемы, описанной в вашем вопросе, я хотел бы выделить третий пример сценария атаки:

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

чтобы предотвратить такую атаку (иногда называемую "радужной атакой"), это предложения OWASP:

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

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

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

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

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

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

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

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

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

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

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

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