Безопасность, криптография:Дурацкий протокол "Вызов - ответ"?
https://stackoverflow.com/questions/188043
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Ладно, ребята, просто небольшая игра:
У меня есть некоторые спецификации для проекта.В какой-то момент они запрашивают следующее для шифрования пароля по сети, говоря, что это протокол ответа на запрос:
CLIENT ----------------------------- SERVER
(1)ask for challenge -------------->
(2) <---------------------------- send SHA1 taken from the time
(this is the challenge)
(3) make SHA1 xor PASSWORD --------> if it's equal to SHA1 xor stored password
(4) <---------------------------- Grant access
Для тех, кто этого не знает, SHA расшифровывается как Secure Hashing Algorithm, стандартный алгоритм криптографии.
Я надеюсь, что это понятно.Вопрос в том,:Если я прослушиваю пакеты 2 и 3 ("вызов" и "вызов пароля xor"), у меня есть фактический пароль, только с другим xor между ними обоими !?!?Есть другой способ реализовать такой протокол??
Решение
Как насчет следующего:
<Ол>Другие советы
Вы сможете восстановить пароль. Вы хотите отправить SHA пароля, а не сам пароль. Использование собственных протоколов безопасности почти никогда не является хорошей идеей. Разве вы не можете использовать SSL или что-то подобное?
Это довольно ужасный протокол.Если это то, что кто-то хочет, чтобы вы реализовали, откажитесь от этого.Существуют существующие, проверенные протоколы для такого рода действий.Если это игра, в которой вы указываете на все недостатки - хорошо.
- Любой, кто слышит шаги 2 и 3, знает пароль
- Любой, кто слышит шаг 3 и отмечает время, может ввести пароль методом перебора, если у него есть какое-либо представление о точности времени на сервере
- Я могу притвориться сервером (отравление arp, изменение dns и т.д.) И получить ваш пароль, так и не выполнив шаг 4 и симулируя тайм-аут
- Уязвим для атак "Человек посередине", поскольку между клиентом и сервером нет общего секрета или сертификатов на сервере
- Полагается на сервер, хранящий SHA1 (время) и ожидающий ответа, поэтому я могу перегрузить сервер запросами на вызовы и никогда не отвечать.
И мне определенно не хватает еще кое-чего.
Вы правы - если вы захватите вызов и (вызов пароля XOR), то извлечь пароль легко.
На шаге 3 необходимо использовать правильное шифрование, а не XOR. Зашифруйте вызов с помощью пароля.
Чтобы сделать жизнь злоумышленника труднее, вы можете добавить случайные данные к тому, что вы шифруете, например: шифрование заполнения CHALLENGEpadding. Сервер не заботится о том, что такое заполнение, он знает, где искать вызов, но это означает, что злоумышленник не будет знать, каков весь открытый текст.
Как уже отмечали другие, вы правы. Также имейте в виду, что кто-то может перехватить связь (3) и потенциально переслать ее, пока реальный пользователь испытывает проблемы с сетью (например, DDOS), тогда самозванец будет входить в систему, и этого часто достаточно для смены пароля (то есть многие системы не требуют, чтобы вы указывали пароль, чтобы изменить его после входа в систему).
Возможно, вы захотите рассмотреть HMAC (код аутентификации хеш-сообщения с ключом). Я подробно писал об этом здесь: http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html , и я дам краткое резюме ниже.
HMAC - это метод, гарантирующий, что сообщение было сгенерировано кем-то, имеющим доступ к общему секрету. HMAC использует своего рода однонаправленную функцию хеширования (например, MD5 или SHA-1) для шифрования секрета вместе с сообщением. Это создает короткий дайджест из 16-20 байтов, который действует как отпечаток комбинации сообщение + секрет. Когда дайджест отправляется вместе с сообщением, получатель (наш сервер) может заново сгенерировать хеш с тем же вычислением HMAC и сравнить локально сгенерированный дайджест с дайджестом, который пришёл вместе с сообщением. Помните: у сервера тоже есть секрет, поэтому у него достаточно информации для подтверждения дайджеста. (При этом рассматривается только проблема проверки источника сообщения, но вы можете использовать тот же подход для шифрования всего сообщения, если вы используете другой секрет, скажем, набор открытых ключей.)
Я бы сделал так:
<Ол>Сервер отвечает своим открытым ключом (например, для шифрования RSA) в цифровом виде подписан.
Клиент проверяет PK и шифрует пароль с ключом, то цифровая подпись зашифрованного пароль.
Сервер проверяет подпись и расшифровывает пароль для хранения / проверки.
Цифровая подпись здесь важна, поскольку она служит началом предотвращения атак человека в середине.
Как уже отмечали другие, да, это плохой алгоритм ответа на вызов.
Возможно, вы захотите проверить дайджест-аутентификацию , используемую в HTTP. На самом деле, если ваш протокол по HTTP, вы можете пропустить написание своего собственного и просто использовать или реализовать его.
шифрование с открытым ключом? Используйте открытый ключ сервера для шифрования пароля.
Хотя это никогда не является хорошим решением для развертывания вашего собственного криптографического протокола, и это то, что я бы не советовал ....
Чтобы преодолеть проблему, с которой вы столкнулись ... F - функция, которая принимает пароль и псевдослучайное монотонно возрастающее значение и возвращает число. Например, Хэш (Hash (Пароль) ^ Метка времени)
<Ол>С уважением, Ашиш Шарма
Я полагаю, что Диффи-Хеллман - это хорошо известный и надежный протокол обмена ключами?
