Как реализовать авторизацию клиентского приложения?

Question

[Николай Васильчук]

Есть два веб-приложения, назову для ясности как Клиент и Сервер.
Клиент запрашивает у Сервера данные, Сервер ему отвечает. Запрос методом POST (или GET) по известному URL, ответ в виде JSON. SSL не используется.

Авторизация Клиента на Сервере происходит по ключу. Клиент отправляет ключ, Сервер его проверяет и обрабатывает (или не обрабатывает) данные.

Потенциально ключ может быть перехвачен злоумышленником, и тогда он получит доступ к данным Сервера.

Проверка Сервером IP Клиента несколько снижает риск, однако это не панацея.

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


Подскажите, как организовать авторизацию Клиента на Сервере максимально безопасно в данной ситуации.

Answer 1

[Роман Василенко]

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

Если же нет, то первое, что приходит в голову, это постоянно изменяющийся идентификатор для каждой пары «вопрос-ответ», который клиент получает у сервера при каждом ответе, а следующим запросом подписывает секретом и возвращает серверу. Если сервер решает, что ключ валидный, он обрабатывает запрос и всё начинается заново.

Comments

[Николай Васильчук]

Рассмотрим ситуацию:
Злоумышленник имеет исходники клиента и сервера, соответственно знает как генерируется и проверяется ключ.
Злоумышленник может перехватить запрос клиента серверу и ответ сервера клиенту.
Соответственно, он может отправить запрос серверу сам (с каким-то ключом), получить ответ, и если в ответе есть секрет, то сгенерировать новый ключ.

Как вообще обычно поступают в такой ситуации? Нужна какая-то наиболее безопасная реализация, которая вкупе с проверкой IP давала бы «условно безопасную» авторизацию.

[Роман Василенко]

Здесь не обойтись без третьей стороны, которая удостоверила бы личность клиента перед сервером и сервера перед клиентом.

[Роман Василенко]

Другими словами, если вы не можете защитить ни сервер, ни клиент, воспользуйтесь услугами защищённого (не вами, а тем, кто может защитить) посредника, который решит, могут ли сервер и клиент доверять друг другу на протяжении данного сеанса взаимодействия.

[Николай Васильчук]

Ниже пишут, что можно обойтись без третьей стороны.

[Роман Василенко]

Вы сами написали, что злоумышленнику доступно ВСЁ.
Не поможет ассиметричное шифрование, если злоумышленнику доступны все ресурсы клиента.

[Николай Васильчук]

Злоумышленнику доступны исходные коды приложений, но ключи же не будут храниться в исходниках.

[Николай Васильчук]

Я вижу это так:
1. На клиенте и на сервере генерируются публичные и приватные ключи.
2. Клиент знает публичный ключ сервера, сервер знает публичный ключ клиента.
3. Клиент подписывает свои запросы публичным ключом сервера, сервер подписывает ответы публичным ключом клиента.

В худшем случае, злоумышленник сможет перехватить зашифрованный запрос клиента и послать его серверу сам, но тогда он не сможет расшифровать ответ сервера. Вкупе с проверкой IP мне кажется, что это достаточно надежная система. Или я ошибаюсь?

[Роман Василенко]

Если у злоумышленника нет доступа к обоим ключам (декодер ответов сервера и кодировщик запросов серверу) — тогда всё нормально должно быть.

[Николай Васильчук]

Ну почти нормально.
Ну зашифровал клиент данные публичным ключом сервера, сервер расшифровал их своим приватным ключом и что-то сделал.
Но если злоумышленник перехватит шифрованный запрос клиента и отправит его сам, то сервер всё равно что-то сделает (ответ сервера злоумышленник конечно не расшифрует, но действие то произойдет). Как бороться с такой ситуацией?

[Роман Василенко]

1. Сервер с каждым ответом присылает некий SID.
2. Клиент подписывает или шифрует запрос этим SID-ом.

[Николай Васильчук]

Тут тоже не всё так просто. Клиентов может быть много и сервер не сможет их отличить. После запросом первого клиента SID для следующей операции другой клиент может попробовать запросить данные с невалидным (уже) SID. Конечно, можно как-то прикрутить сессии, но я пока смутно представляю, как работать с сессиями (с клиентской стороны) на php.

[Роман Василенко]

Очень просто. Клиент сохраняет SID в файл или в базу данных. Если клиент не клиент, а прокси, то SID ассоциируется с ID клиента нашего клиента (который не клиент, а прокси).

Answer 2

[Игорь]

Если исходники открыты, то единственный вариант — асимметричное шифрование с публичными ключами.
Клиент и сервер обмениваются публичными ключами, секретные оставляют у себя.

Реализаций много. Одна из возможных:

1. Клиент соединяется с сервером, предоставляет ему свой публичный ключ
2. сервер посылает клиенту вопрос, подписанный публичным ключом клиента
3. клиент используя свой закрытый ключ выясняет вопрос сервера, решает вопрос и подписывает его публичным ключом сервера, передаёт серверу
4. сервер применяет к ответу свой секретный ключ, тем самым снимая шифрование, и проверяет ответ. если всё ок — сервер считает, что клиент подтверждён.

возможно то же самое, но в другую сторону для того, чтоб клиент проверил Сервер

Comments

[Николай Васильчук]

Это интересная идея. Не подскажете, что можно почитать по этому поводу? Или какие-нибудь реализации.

[Игорь]

Можно воспользоваться тем, что PHP имеет функции работы с openssl.
А тот, в свою очередь, предоставляет очень много криптоалгоритмов.

Вот ещё пара ссылок по теме:
pear.php.net/package/Crypt_RSA
www.phpclasses.org/package/4121-PHP-Encrypt-and-decrypt-data-with-RSA-public-keys.html

ну и спросим гугл правильно

[Николай Васильчук]

А почему нельзя использовать симметричное шифрование? Скажем, клиент и сервер знают какой-то ключ. Им они шифруют и расшифровывают данные. Ключ перехватить невозможно, т.к. он не передается. От шифрованных данных толку мало.

[Игорь]

Если исходники доступны — то и ключ известен. Значит, толку от шифрования мало

[Николай Васильчук]

shanker, ключ не хранится в исходниках. Есть файл настроек (или БД) клиента и сервера), там нужно будет вписать ключ.

[Игорь]

Ключ клиентов и сервера одинаковый? Тогда любой клиент (или тот, у кого есть файлы клиента вместе с ключом шифрования) сможет расшифровать данные других клиентов. Если это не критично, то не совсем ясно зачем вообще использовать шифрование, коли это могут расшифровать другие?

[Николай Васильчук]

shanker, я могу на сервере в настройках хранить ключи всех клиентов и любую другую информацию. Не передавать их в открытую, а при добавлении нового клиента открыть конфиг сервера и прописать туда новый ключ.

[Игорь]

Anonym, если для каждого клиента свой ключ — да, это имеет смысл. Но тогда следите, чтоб в трафике не было зашифрованных сообщений, расшифрованное тело которых можно предсказать. Тогда ключ подберётся легко.

Пример: в каком-то случае сообщаете пользователю, что команда выполнена успешно. И это сообщение фиксировано. Но закрыто ключом. Тогда мы просто ждём это сообщение (вычислить его среди всех зашифрованных несложно) и раскрываем ключ.

Answer 3

[Роман Сопов]

1. Используйте RSA
2. Храните ключ на клиенте в зашифрованном на основе логина и пароля виде.
3. Для авторизации используйте механизм электронной подписи:
   
   • Сервер отправляет случайно сгенерированную строку, типа $sKey = md5(rand())
   • Клиент тоже генерит случайную строку по тому же типу $cKey = md5(rand())
   • Склеиваем строки и подписываем их хэш с помощью закрытого ключа RSA (на JS реализаций полно) типа sign(sha256($sKey+$cKey))
   • Отправляем на сервер подпись и сгенерированную на клиенте строку
   • На сервере проверяем подпись с помощью открытого ключа
   
   

Или используйте Рутокен Web, но это его работы нужно плагин устанавливать.

Comments

[Николай Васильчук]

1. При использовании RSA есть проблема. Клиент знает публичный ключ сервера, шифрует им данные и передает на сервер. Злоумышленник перехватывает шифрованный запрос клиента и может отправить его серверу (а сервер его без проблем расшифрует своим приватным ключом). Конечно же злоумышленник не сможет расшифровать ответ сервера, но сервер на запрос злоумышленника уже выполнит какое-то действие, а не должен бы.
2. Нет никаких логинов и паролей. Клиент и сервер — это приложения на php.
3. См. п.1

Рутокен Web вообще не понимаю как может мне помочь.

[FanKiLL]

Как вариант в зашифрованном теле, ввести ещё 1 поле TTL в которой будет хранится (timestamp) отправки, на сервере проверяем если TTL не старше определённого времени например 3 минуты. Так если злоумышленник соберёт уже подписанные сообщения он не сможет ими бомбить сервер, вернее отослав на сервере ничего не произойдет.

А вообще вы поставили жёсткие рамки.

[Роман Сопов]

Видимо не так понял… Тогда тут только SSL или что-то подобное.
Клиент с Сервером должны обменяться открытыми ключами по доверенному каналу. Далее Клиент обращается к Серверу. Сервер генерит сессионный ключ, зашифровывает его открытым ключом Клиента и отправляет его.
Клиент получает сессионный ключ и расшифровывает его своим закрытым ключом.
Далее вся информация шифруется этим сессионным ключом. Т.к. злоумышленник не будет знать этот ключ то и данные он не подменит и не прочитает.
Если обеспечить безопасный обмен открытыми ключами и надежно хранить закрытые, то все будет ОК.

[Николай Васильчук]

FanKiLL, TTL не вариант. Я не уверен, что время на сервере и клиенте будет совпадать ) А делать +1 запрос к серверу, чтобы тот запомнил время и ожидал следующий запрос 3 минуты — это не вариант. Да, рамки довольно жесткие, но мы ведь обсуждаем различные варианты в поисках «условно идеального». В идеале мне хотелось бы как-то так: на клиенте и сервере в настройках сохраняем (ручками при установке) какие-то данные (ключи или что-то подобное). И чтобы после этого клиент мог отправить 1 запрос с данными, а сервер понял, что это клиент, а не злоумышленник (если злоумышленник отправит точно такой же запрос, сервер должен ему отказать). Для такой «идеальной» реализации было бы отлично использовать какой-то постоянно изменяющийся ключ, чтобы 2 одинаковых запроса клиента в зашифрованном виде были разными. Неплохо было бы завязаться на время (скажем, шифр зависит от времени и изменяется раз в 5 секунд), но я не уверен, что время будет совпадать.

AstralMan, если обмениваться открытыми ключами по доверенному каналу, то они вовсе не нужны. Можно использовать синхронное шифрование. Сессионный ключ тут не поможет, злоумышленнику не обязательно расшифровывать данные, он просто отправит зашифрованные данные серверу, а сервер уже не поймет, что это не клиент и выполнит какое-то действие.

[Роман Сопов]

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

> Можно использовать синхронное шифрование. Сессионный ключ тут не поможет, злоумышленнику не обязательно
> расшифровывать данные, он просто отправит зашифрованные данные серверу
Ну отправил он данные серверу, и что? Получит ответ от сервера, а что он с ним будет делать не знаю сессионного ключа???

>а сервер уже не поймет, что это не клиент и выполнит какое-то действие.
В каждом запросе можно передавать ID сессии который генерить Сервер при первом обращении Клиента.

[FanKiLL]

По сути вы пытаетесь имплементировать PGP.
Если у вас не один клиент конечно — Встаёт вопрос, что посылать вместе с зашифрованным телом, нужен какой то идентификатор чтоб сервер знал какой ключ ему применить для расшифровки (имя пользователя или id и т. д. к которому привязан сессионный ключ). Вы же не будете в for расшифровать применяя все ключи пока не расшифруете.

То есть изначально задача стоит авторизовать безопасно юзера, для этого он должен передать что то на сервер, об чём этот сервер знает и ассоциирует с этим клиентом. Причём передавать надо каждый запрос. Сам алгоритм шифрования тут не так важен, если злоумышленник может перехватить это что то что клиент передаёт для идентификации. Тогда злоумышленник просто может бомбить сервер ложными сообщениями, ничего с данными не будет, но вы будете тратить серверные ресурсы ибо будете пытаться расшифровать тело сообщения.

[Николай Васильчук]

AstralMan, Я смогу сгенерировать сессионный ключ и зашифровать его ключом, который знает клиент и знает сервер. Этим же ключом клиент расшифрует сессионный ключ. Злоумышленник расшифровать его не сможет. Ответ сервера злоумышленника не интересует, он отправит данные, а сервер что-то сделает (удалит запись, включит модуль, вышлет солдат в Таганрог, etc.).

FanKiLL, ну клиент может представиться в открытую, мол «я %clientUniqueName%», а данные отправить шифрованные.

[FanKiLL]

Anonym Тогда остаётся проблема, злоумышленник бомбит сервер отсылаю %clientUniqueName% + какой то текст, вы тратите серверные ресурсы пытаясь разшифровать + понять действительно ли данные расшифровались например проверка есть ли како-то поле…

Мне кажется нужно вначале решить проблему идентификации, чтобы ненужные запросы отвергались на этом этапе, второй этап расшифровка. То что вы описали решает одну проблему третье лицо не может прочитать/изменить данные.
Остаются проблемы:
1) Сбор уже зашифрованных сообщений и повторная отправка их на сервер(например если это команда добавить что то в базу, в лучшем случае вы сделаете проверку на дубль и ничего не произойдёт, в худшем будете заспамленны)
2) Трата ресурсов на дешифровку левых сообщений.

Answer 4

[Роман Сопов]

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

Answer 5

[1nd1go]

Для защиты от Man-in-the-middle attack вам поможет шифрование транспорта или сообщений.
Т.е. вы либо шифруете уровень передачи данных, а значит используете SSL, либо сообщения на уровне приложения. В эпоху фреймворков проще делать через SSL.

А вообще, первая глава и вторая глава, пункт 2.2 книги Прикладная Криптография, Брюса Шнайера. для вас