Безопасность, криптография: глупый вызов - протокол ответа?

Question

Ок, ребята, просто маленькая игра:

У меня есть некоторые спецификации для проекта. В какой-то момент они просят следующее зашифровать пароль по сети, заявив, что это протокол ответа на запрос:

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 обозначает алгоритм безопасного хеширования, стандартный алгоритм криптографии.

Надеюсь, это понятно. Вопрос: если я сниффинг пакетов 2 и 3 («вызов» и «пароль вызова xor», у меня есть действительный пароль, просто с другим xor между ними! ??

Answer 1

Вы сможете восстановить пароль. Вы хотите отправить SHA пароля, а не сам пароль. Использование собственных протоколов безопасности почти никогда не является хорошей идеей. Разве вы не можете использовать SSL или что-то подобное?

http://en.wikipedia.org/wiki/Cryptographic_nonce

Answer 2

Как насчет следующего:

1. Сервер отправляет случайный вызов
2. Клиент отправляет контрольную сумму SHA1 (вызов + пароль)
3. Серверы сравнивают с контрольной суммой SHA1 (вызов + сохраненный пароль)

Answer 3

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

• Любой, кто слышит шаги 2 и 3, знает пароль
• Любой, кто слышит шаг 3 и отмечает время, может взломать пароль, если у него есть представление о точности времени на сервере
• Я могу притвориться сервером (отравление arp, переадресация днс и т. Д.) И получить ваш пароль, никогда не завершая шаг 4 и симулируя таймаут
• Уязвим к атакам типа «человек посередине», потому что нет общего секрета между клиентом / сервером или сертификатами на сервере
• Полагается на сервере, хранящем SHA1 (время) и ожидающем ответа, поэтому я могу перегружать сервер запросами на вызовы и никогда не отвечать.

И я определенно пропускаю еще немного.

Answer 4

Как указали другие, вы правы. Также имейте в виду, что кто-то может перехватить связь (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 и сравнить локально сгенерированный дайджест с дайджестом, который пришёл вместе с сообщением. Помните: у сервера тоже есть секрет, поэтому у него достаточно информации для подтверждения дайджеста. (Это рассматривает только проблему проверки происхождения сообщения, но вы можете использовать тот же подход для шифрования всего сообщения, если вы используете другой секрет, скажем, набор открытых ключей.)

Answer 5

Вы правы - если вы захватили вызов и (вызов пароля XOR), то извлечь пароль легко.

На шаге 3 необходимо использовать правильное шифрование, а не XOR. Зашифруйте вызов с помощью пароля.

Чтобы сделать жизнь злоумышленника труднее, вы можете добавить случайные данные к тому, что вы шифруете, например: шифрование заполнения CHALLENGEpadding. Сервер не заботится о том, что такое заполнение, он знает, где искать вызов, но это означает, что злоумышленник не знает, каков весь открытый текст.

Answer 6

Я полагаю, что Диффи-Хеллман - это хорошо известный и надежный протокол обмена ключами?

Answer 7

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

Чтобы преодолеть проблему, с которой вы столкнулись ... F - функция, которая принимает пароль и псевдослучайное монотонно возрастающее значение и возвращает число. Например, Хеш (Хеш (Пароль) ^ Метка времени)

1. Сервер: запрос вызова, отправка (отметка времени). Запомните последнюю отправленную временную метку.
2. Клиент, Отправить ответ (Отправить F (пароль, отметка времени) и отметка времени)
3. Сервер: проверка клиента с использованием хэша (пароля) и отметки времени, отправленной клиентом (> отметка времени, отправленная в вызове).
4. Если Клиент правильный, предоставьте доступ.
5. Убедитесь, что текущая временная метка больше, чем все отправленные клиентом временные метки до следующего вызова, чтобы предотвратить повторные атаки.

С уважением, Ашиш Шарма

Answer 8

шифрование с открытым ключом? Используйте открытый ключ сервера для шифрования пароля.

Answer 9

Как уже отмечали другие, да, это плохой алгоритм ответа на вызов.

Возможно, вы захотите проверить дайджест-аутентификацию , используемую HTTP. На самом деле, если ваш протокол по HTTP, вы можете пропустить написание своего собственного и просто использовать или реализовать его.

Answer 10

Я бы сделал так:

1. Бросьте вызов серверу.

2. Сервер отвечает своим открытым ключом (например, для шифрования RSA) в цифровом виде подписан.

3. Клиент проверяет PK и шифрует пароль с ключом, то цифровая подпись зашифрованного пароль.

4. Сервер проверяет подпись и расшифровывает пароль для хранения / проверки.

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