Если у злоумышленника есть исходные данные и зашифрованные данные, могут ли они определить пароль? - PullRequest
13 голосов
/ 06 апреля 2010

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

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

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

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

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

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

Ответы [ 5 ]

12 голосов
/ 06 апреля 2010

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

Вы захотите немного почитать о крипто.

5 голосов
/ 06 апреля 2010

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

3 голосов
/ 07 апреля 2010

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

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

3 голосов
/ 06 апреля 2010

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

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

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

1 голос
/ 07 апреля 2010

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

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

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

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

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

и так далее. Как видите, вы получаете поток ключей обратно. Не ключ, а поток, сгенерированный ключом.

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