Если у взломщика есть исходные данные и зашифрованные данные, они могут определить пароль?
Если у взломщика есть несколько отличных объектов (например: адреса электронной почты), и знает зашифрованное значение каждого объекта, взломщик может более легко решить, что секретный пароль раньше шифровал те объекты? Значение, они могут определить пароль, не обращаясь к грубой силе?
Этот вопрос может звучать странным, таким образом позвольте мне обеспечить пример использования:
- Пользователь подписывается под сайтом с их адресом электронной почты
- Сервер отправляет тому адресу электронной почты URL подтверждения (например: https://my.app.com/confirmEmailAddress/bill%40yahoo.com)
- Взломщик может предположить URL подтверждения и поэтому может подписаться с чужим адресом электронной почты и 'подтвердить' это, никогда не имея необходимость регистрироваться к почтовому ящику того человека и видеть URL подтверждения. Это - проблема.
- Вместо того, чтобы отправить простой текст адреса электронной почты в URL, мы отправим зашифрованный секретным паролем.
- (Я знаю, что взломщик мог все еще прервать электронное письмо, посланное сервером, так как электронное письмо является простым текстом, но терпите меня здесь.)
- Если взломщик затем подписывается с несколькими свободными почтовыми ящиками и видит несколько URL, каждого с соответствующим зашифрованным адресом электронной почты, взломщик мог более легко определить пароль, используемый для шифрования?
Альтернативное решение
Я мог вместо этого отправить случайное число или односторонний хэш их адреса электронной почты (плюс случайная соль). Это устраняет хранение секретного пароля, но это означает, что я должен сохранить то случайное число / хеш в базе данных. Исходный подход выше не требует устройства хранения данных в базе данных.
Я склоняюсь к one-way-hash-stored-in-the-db, но я все еще хотел бы знать ответ: наличие нескольких незашифрованных адресов электронной почты и их зашифрованных дубликатов помогает определить используемый пароль?
5 ответов
Хотя вы, вероятно, сможете после некоторых исследований выбрать достаточно надежный криптографический метод, чтобы противостоять атаке с использованием известного открытого текста, действительно ли стоит просто избегать хранения хэша в вашей базе данных?
Использование единственной парольной фразы для шифрования все запросы на регистрацию выглядят так, как будто вы добавляете ненужную единичную уязвимость: если злоумышленник каким-то образом взломает эту парольную фразу, он может зарегистрировать столько учетных записей, сколько захочет. Если, с другой стороны, вы генерируете для каждого нового запроса учетной записи одноразовый хэш (например, адрес электронной почты + случайное число) для аутентификации URL-адреса подтверждения, даже хакер, который перехватывает электронное письмо с подтверждением для учетной записи A, не станет ближе для получения доступа к B, C или D.
Вы, вероятно, захотите сохранить некоторую информацию о состоянии процесса подтверждения в базе данных: вероятно, должно быть ограничение по времени на то, как долго URL подтверждения действителен.
Да, это действительно упрощает задачу. В целом, чем больше информации у злоумышленника, тем легче становится его работа. Этот конкретный пример называется атакой с использованием известного открытого текста .
Вы описываете атаку с использованием известного открытого текста . Классические шифры были очень уязвимы для такого рода атак, но современные шифры созданы, чтобы противостоять им.
Вы захотите немного почитать о криптографии.
Есть один сценарий, в котором ответ - ДА !!! И это если вы используете потоковый шифр, например RC4.
RC4 - это, по сути, генератор случайных чисел, который просто выполняет XOR открытого текста с «ключевым потоком», полученным из вашего ключа:
P0 ^ K0 = C0
P1 ^ K1 = C1
P2 ^ K2 = C2
.
.
PN ^ KN = CN
Если у вас есть и открытый, и зашифрованный текст, вы можете сделать это:
C0 ^ P0 = K0
C1 ^ P1 = K1
C2 ^ P2 = K2
и так далее. Как видите, вы получаете обратно ключевой поток. Не ключ, а поток, генерируемый ключом.
Вам нужно не шифрование, а аутентификация. В ссылку, которую вы отправляете клиентам, вы включаете не только их адрес электронной почты, но и метку времени, а также так называемый MAC, который представляет собой поле аутентификации на основе симметричного ключа. MAC должен подтверждать подлинность как адреса электронной почты, так и метки времени. 64-битный HMAC-SHA1 должен подойти. Когда вы получите ссылку, проверьте, что временная метка не слишком далеко в прошлом, и MAC подтвердит ее; тогда вы будете знать, что сгенерировали ссылку.
MAC разработаны для защиты от атак, в которых злоумышленники выбирают сообщения и запрашивают соответствующие MAC, поэтому вам не нужно беспокоиться о MAC-эквиваленте "атаки с известным открытым текстом".