Почти любые роутеры для которых есть OpenWRT или «прошивка от Олега». Для них есть драйверы на звуковуху. Проверено на D-Link Dir-320 и каком-то старом асусе.
shanker, я могу на сервере в настройках хранить ключи всех клиентов и любую другую информацию. Не передавать их в открытую, а при добавлении нового клиента открыть конфиг сервера и прописать туда новый ключ.
AstralMan, Я смогу сгенерировать сессионный ключ и зашифровать его ключом, который знает клиент и знает сервер. Этим же ключом клиент расшифрует сессионный ключ. Злоумышленник расшифровать его не сможет. Ответ сервера злоумышленника не интересует, он отправит данные, а сервер что-то сделает (удалит запись, включит модуль, вышлет солдат в Таганрог, etc.).
FanKiLL, ну клиент может представиться в открытую, мол «я %clientUniqueName%», а данные отправить шифрованные.
FanKiLL, TTL не вариант. Я не уверен, что время на сервере и клиенте будет совпадать ) А делать +1 запрос к серверу, чтобы тот запомнил время и ожидал следующий запрос 3 минуты — это не вариант. Да, рамки довольно жесткие, но мы ведь обсуждаем различные варианты в поисках «условно идеального». В идеале мне хотелось бы как-то так: на клиенте и сервере в настройках сохраняем (ручками при установке) какие-то данные (ключи или что-то подобное). И чтобы после этого клиент мог отправить 1 запрос с данными, а сервер понял, что это клиент, а не злоумышленник (если злоумышленник отправит точно такой же запрос, сервер должен ему отказать). Для такой «идеальной» реализации было бы отлично использовать какой-то постоянно изменяющийся ключ, чтобы 2 одинаковых запроса клиента в зашифрованном виде были разными. Неплохо было бы завязаться на время (скажем, шифр зависит от времени и изменяется раз в 5 секунд), но я не уверен, что время будет совпадать.
AstralMan, если обмениваться открытыми ключами по доверенному каналу, то они вовсе не нужны. Можно использовать синхронное шифрование. Сессионный ключ тут не поможет, злоумышленнику не обязательно расшифровывать данные, он просто отправит зашифрованные данные серверу, а сервер уже не поймет, что это не клиент и выполнит какое-то действие.
Тут тоже не всё так просто. Клиентов может быть много и сервер не сможет их отличить. После запросом первого клиента SID для следующей операции другой клиент может попробовать запросить данные с невалидным (уже) SID. Конечно, можно как-то прикрутить сессии, но я пока смутно представляю, как работать с сессиями (с клиентской стороны) на php.
При использовании RSA есть проблема. Клиент знает публичный ключ сервера, шифрует им данные и передает на сервер. Злоумышленник перехватывает шифрованный запрос клиента и может отправить его серверу (а сервер его без проблем расшифрует своим приватным ключом). Конечно же злоумышленник не сможет расшифровать ответ сервера, но сервер на запрос злоумышленника уже выполнит какое-то действие, а не должен бы.
Нет никаких логинов и паролей. Клиент и сервер — это приложения на php.
См. п.1
Рутокен Web вообще не понимаю как может мне помочь.
А почему нельзя использовать симметричное шифрование? Скажем, клиент и сервер знают какой-то ключ. Им они шифруют и расшифровывают данные. Ключ перехватить невозможно, т.к. он не передается. От шифрованных данных толку мало.
Ну почти нормально.
Ну зашифровал клиент данные публичным ключом сервера, сервер расшифровал их своим приватным ключом и что-то сделал.
Но если злоумышленник перехватит шифрованный запрос клиента и отправит его сам, то сервер всё равно что-то сделает (ответ сервера злоумышленник конечно не расшифрует, но действие то произойдет). Как бороться с такой ситуацией?
Я вижу это так:
1. На клиенте и на сервере генерируются публичные и приватные ключи.
2. Клиент знает публичный ключ сервера, сервер знает публичный ключ клиента.
3. Клиент подписывает свои запросы публичным ключом сервера, сервер подписывает ответы публичным ключом клиента.
В худшем случае, злоумышленник сможет перехватить зашифрованный запрос клиента и послать его серверу сам, но тогда он не сможет расшифровать ответ сервера. Вкупе с проверкой IP мне кажется, что это достаточно надежная система. Или я ошибаюсь?
Рассмотрим ситуацию:
Злоумышленник имеет исходники клиента и сервера, соответственно знает как генерируется и проверяется ключ.
Злоумышленник может перехватить запрос клиента серверу и ответ сервера клиенту.
Соответственно, он может отправить запрос серверу сам (с каким-то ключом), получить ответ, и если в ответе есть секрет, то сгенерировать новый ключ.
Как вообще обычно поступают в такой ситуации? Нужна какая-то наиболее безопасная реализация, которая вкупе с проверкой IP давала бы «условно безопасную» авторизацию.
Lux_In_Tenebris, это удобно. Один алгоритм для всех пользователей. Позднее усовершенствовал алгоритм, сессия теперь стартует при первом обращении к ней. Смысл от этого не меняется.
lazychaser, Ну а чего вы хотели? Оценить доработки существующего сайта (а именно это подразумевается под «натянуть эти странички на готовый движок, который имеет практически весь необходимый функционал») в принципе невозможно. В том движке может быть такой говнокод, что быстрее будет написать сайт с нуля, чем натягивать дизайн на существующий.
