Если злоумышленник имеет исходные данные и зашифрованные данные, может ли они определить кодовую фразу?

Если злоумышленник имеет несколько отдельных элементов (например: адреса электронной почты) и знает зашифрованное значение каждого элемента, может ли злоумышленник легче определить секретную кодовую фразу, используемую для шифрования этих элементов? Смысл, могут ли они определить кодовую фразу, не прибегая к грубой силе?

Этот вопрос может показаться странным, поэтому позвольте мне привести пример использования:

  • Пользователь подписывается на сайт с адресом электронной почты
  • Сервер отправляет этот адрес электронной почты URL-адрес подтверждения (например: https://my.app.com/confirmEmailAddress/bill%40yahoo.com)
  • Атакующий может угадать URL-адрес подтверждения и, следовательно, может зарегистрироваться с другим адресом электронной почты и "подтвердить" его, даже не войдя в учетную запись электронной почты этого человека и не увидите URL-адрес подтверждения. Это проблема.
  • Вместо того, чтобы отправлять URL-адрес обычного текста в URL-адрес, мы отправим его зашифрованным секретной кодовой фразой.
  • (Я знаю, что злоумышленник все равно может перехватить сообщение электронной почты, отправленное сервером, поскольку электронная почта - это простой текст, но нести меня здесь.)
  • Если злоумышленник регистрируется с несколькими бесплатными учетными записями электронной почты и видит несколько URL-адресов, каждый с соответствующим зашифрованным адресом электронной почты, может ли злоумышленник легче определить кодовую фразу, используемую для шифрования?

Альтернативное решение

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

Я склоняюсь к односторонней-хэш-памяти в-дБ, но мне все же хотелось бы знать ответ: имеет ли несколько нешифрованных адресов электронной почты и их зашифрованные копии упрощает определить используемую ключевую фразу?

ОТВЕТЫ

Ответ 1

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

Использование одной парольной фразы для шифрования всех запросов на регистрацию похоже на то, что вы добавляете ненужную одноточечную уязвимость: если злоумышленник каким-то образом взломает эту кодовую фразу, они могут регистрировать столько учетных записей, сколько захотят. Если, с другой стороны, вы генерируете для каждого нового запроса учетной записи одноразовый хэш (например, адрес электронной почты + случайное число, например) для аутентификации URL-адреса подтверждения, даже хакер, который перехватывает адрес электронной почты подтверждения для учетной записи A, не ближе для доступа к B, C или D.

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

Ответ 2

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

Вам нужно немного прочитать криптографию.

Ответ 4

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

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

Ответ 5

Есть один сценарий, где ответ ДА ​​!!! И это если вы используете шифр потока, например RC4.

RC4 по существу является генератором случайных чисел, который просто XOR создает открытый текст с "ключевым потоком", полученным из вашего ключа:

P0 ^ K0 = C0
P1 ^ K1 = C1
P2 ^ K2 = C2
 .
 .
PN ^ KN = CN

Если у вас есть как открытый текст, так и зашифрованный текст, вы можете сделать это:

C0 ^ P0 = K0
C1 ^ P1 = K1
C2 ^ P2 = K2

и т.д. Как вы можете видеть, вы возвращаете ключевой поток. Не ключ, а поток, генерируемый ключом.