Безопасность, криптография: глупый вызов - протокол ответа?
Ладно, ребята, небольшая игра:
У меня есть спецификации для проекта. В какой-то момент они просят следующее для шифрования пароля в сети, говоря, что это протокол ответа на запрос:
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 между ними обоими!?!? Есть другой способ реализовать этот вид протокола ??
Ответы 10
Вы сможете реконструировать пароль. Вы хотите отправить SHA пароля, а не сам пароль. Использование собственных протоколов безопасности почти никогда не бывает хорошей идеей. Разве вы не можете использовать SSL или что-то подобное?
http://en.wikipedia.org/wiki/Cryptographic_nonce
Вы правы - если вы перехватите вызов и (вызовите пароль XOR), то извлечь пароль будет легко.
На шаге 3 необходимо использовать правильное шифрование, а не XOR. Зашифруйте вызов паролем.
Чтобы усложнить жизнь злоумышленнику, вы можете добавить случайные данные к тому, что вы зашифровываете: например, зашифровать заполнениеCHALLENGEpadding. Серверу все равно, что такое заполнение, он знает, где искать проблему, но это означает, что злоумышленник не будет знать, что такое весь открытый текст.
Это предсказуемый шаблон, который можно использовать. Не хорошая идея.
безопасность через неизвестность - это вовсе не безопасность
В вопросе я не понимаю, какое значение имеет часть SHA1 - проблема может быть любой. Вам не нужно отменять хеширование, если я не понимаю описание. Где часть безвестности? Добавление заполнения аналогично использованию соли при хранении пароля для предотвращения известных атак с открытым текстом.
Проблема в том, что xor по сути обратим. Если у вас есть pw ^ s1hash и s1hash отдельно, вы можете восстановить pw, выполнив pw ^ s1hash ^ s1hash, чтобы отменить исходный xor. (^ вот операция xor)
@ pabloh84: если вы замените xor, скажем, на SHA1, вы просто сделаете один и тот же SHA1 с обеих сторон. Как указывали другие, вам нужна односторонняя операция (по крайней мере) вместо XOR.
@Rob Walker Salt увеличивает энтропию хешированного пароля. Добавление в пароль случайных байтов не делает ничего, кроме скрытия сообщения. Например, если кто-то выясняет, что пароль нужно дополнить, это не дает никаких преимуществ.
@ gdean2323 - я не заполнял пароль, я предлагал заполнить задачу и зашифровать ее потом (с использованием «правильного» алгоритма шифрования, а не XOR).
Тем не менее, заполнение ничего не добавляет с точки зрения безопасности. Вы также можете просто сказать, что используйте «правильное» шифрование.
Это довольно ужасный протокол. Если кто-то хочет, чтобы вы это реализовали, откажитесь. Для такого рода вещей существуют проверенные протоколы. Если это игра, в которой вы указываете на все недостатки - хорошо.
- Любой, кто слышит шаги 2 и 3, знает пароль
- Любой, кто слышит шаг 3 и отмечает время, может подобрать пароль, если он имеет какое-либо представление о точности времени на сервере.
- Я могу притвориться сервером (отравление arp, переадресация DNS и т. д.) И получить ваш пароль, никогда не выполняя шаг 4 и симулируя тайм-аут
- Уязвим к средним атакам, потому что нет общего секрета между клиентом / сервером или сертификатами на сервере
- Полагается на сервер, хранящий SHA1 (время) и ожидающий ответа, поэтому я могу перегружать сервер запросами на вызовы и никогда не отвечать.
И я определенно упускаю еще кое-что.
Как отметили другие, вы правы. Также имейте в виду, что кто-то может перехватить сообщение (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 и сравнить локально сгенерированный дайджест с дайджестом, который пришел вместе с сообщением. Помните: у сервера тоже есть секрет, поэтому у него достаточно информации для подтверждения дайджеста. (Здесь рассматривается только проблема проверки происхождения сообщения, но вы можете использовать тот же подход для шифрования всего сообщения, если вы используете другой секрет, скажем, набор открытых ключей.)
Как насчет следующего:
- Сервер отправляет случайный запрос
- Клиент отправляет контрольную сумму SHA1 (запрос + пароль)
- Серверы сравнивают с контрольной суммой SHA1 (запрос + сохраненный пароль)
Я бы сделал это следующим образом:
- Бросьте вызов серверу.
Сервер отвечает своим открытым ключом (например, для шифрования RSA) в цифровом виде подписано.
Клиент проверяет PK и шифрует пароль с ключом, затем цифровая подпись зашифрованного пароль.
Сервер проверяет подпись и расшифровывает пароль для его хранения / проверки.
Цифровая подпись здесь важна, поскольку она действует как начало предотвращения атак посредника.
Этот не предотвращает атаки человека посередине, поскольку человек посередине может заменить ключ клиента или сервера своим собственным, если у вас нет CA - в этом случае вы только что воссоздали SSL (и должны использовать его вместо этого).
Как отмечали другие, да, это плохой алгоритм ответа на вызов.
Вы, вероятно, захотите проверить Дайджест-аутентификация, используемый HTTP. Фактически, если ваш протокол работает через HTTP, вы можете не писать свой собственный и просто использовать или реализовать его.
шифрование с открытым ключом? Используйте открытый ключ сервера, чтобы зашифровать пароль.
Хотя развертывание собственного криптографического протокола никогда не является хорошим решением, и я бы не стал предлагать этого ...
Чтобы преодолеть проблему, с которой вы столкнулись ... F - функция, которая принимает пароль и псевдослучайное монотонно возрастающее значение и возвращает число. Например, Хеш (Хеш (Пароль) ^ Метка времени)
- Сервер: запросить вызов, отправить (отметка времени). Запомнить последнюю отправленную метку времени.
- Клиент, отправить ответ (отправить F (пароль, метка времени) и метка времени)
- Сервер: проверьте клиента, используя хэш (пароль) и метку времени, отправленную клиентом (> метку времени, отправленную в запросе).
- Если Клиент верен, предоставьте доступ.
- Убедитесь, что текущая временная метка больше, чем все временные метки, отправленные клиентом перед следующим вызовом, чтобы предотвратить атаки повторного воспроизведения.
С уважением, Ашиш Шарма
Я считаю, что Diffie-hellman - это хорошо известный и надежный протокол обмена ключами?
Nonces похожи на временные соли :)