Блог

Ладно, ребята, просто небольшая игра:

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

КЛИЕНТ ----------------------------- СЕРВЕР

(1)попросите о вызове -------------->

(2) 
 (это и есть вызов)
(3) сделайте ПАРОЛЬ SHA1 xor - - - - - - - ->, если он равен сохраненному паролю SHA1 xor

(4) 

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

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

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

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

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

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

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

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

И мне определенно не хватает еще кое-чего.

Вы правы-если вы поймаете вызов и (вызовите пароль XOR), то извлечь пароль будет легко.

Вам нужно использовать правильное шифрование на шаге 3, а не XOR. Зашифруйте вызов паролем.

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

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

Я бы сделал это следующим образом:

1. Бросьте вызов серверу.
2. Сервер отвечает своим открытым ключом (например, для шифрования RSA) с цифровой подписью.
3. Клиент проверяет PK и шифрует пароль с помощью ключа, затем подписывает зашифрованный пароль цифровой подписью.
4. Сервер проверяет подпись и расшифровывает пароль, чтобы сохранить/проверить его.

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

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

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

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

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

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

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

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

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