Аутентификация flash-клиента у PHP-сервера. Варианты?

[SevMadVic]

Аутентификация flash-клиента у PHP-сервера. Варианты?

Собственно, сабж. Есть демон, написанный на PHP. К нему подключаются клиентские flash-приложения. Необходимо организовать обмен ключами или ещё какой-нибудь способ аутентификации flash-приложений у PHP-демона. Какие предложения?

Например: PHP-демон, после подключения к нему flash-клиента, генерит случайную строку и отсылает её клиенту. Flash-клиент изменяет эту строку по определённмоу алгоритму и отсылает обратно PHP-демону. Тот обрабатывает исходную строку по такому же алгоритму и сравнивает полученный результат с ответом от flash-клиента. Если совпадает, продолжается обмен данными, если нет - соединение закрывается...

Вопрос, каким образом лучше всего организовать подобный алгоритм обработки строки средствами PHP и Flash с целью достижения максимальной устойчивости к взлому? А также, что немаловажно, внести возможность изменять этот алгоритм у PHP-демона и flash-клиента одновременно, путём введения в алгоритм какого-нибудь уникального ключа.

Или, может, будут ещё варианты? Заранее благодарен за помощь.

 

[Фанат]

Ну, тут описан практически вариант digest авторизации.
только непонятно, от какого взлому мы защищаемся.
разве нельзя декомпилировать этот флеш и посмотреть, что у него внутри?

 

[SevMadVic]

Необходимо придумать способ, который позволит PHP-демону убедиться, что он обменивается данными именно с flash-клиентом, а не с другим приложением, имитирующим поведение flash-мувика. Если такая задача вообще осуществима.

 

[Фанат]

я думаю, что нет.

-~{}~ 13.02.10 22:28:

можно идентифицировать только браузер, но это опять же, будет личная идентификация игрока, а не апплета

 

[Fortop]

В теории можно попытаться с некоторой периодичностью пересобирать flash для каждого пользователя индивидуально. Вшивая некий pid в виде хэша. А демон у себя будет брать ip и еще какой-нибудь мусор с хоста с которого пришел запрос, генерить хэш и проверять на соответствие этому pid.

Но это зело запутано, да и ресурсоемко.

 

[Фанат]

Fortop
Здесь совсем другая картина.
При обычной авторизации мы с клиентом играем сообща против третьей стороны.
А здесь сервер играет против клиента.
Я думаю, что без шансов. Ave novie - nostra ales, что означает: Ежели один человек построил, другой завсегда разобрать может

 

[Fortop]

Автор оригинала: *****
Я думаю, что без шансов.

Я тоже так думаю
Скорее вопрос может стоять в минимизации ущерба. А это зависит уже от того, что же именно хотят закрыть/запретить.

 

[SevMadVic]

Ясно. Значит, никаких вариантов полностью исключить возможность стороннего подключения к демону нет. А как в таком случае можно по максимуму усложнить задачу злоумышленнику?

Вариант по поводу пересобирания flash-мувика довольно интересный, но я себе пока не представляю, как это можно сделать средствами PHP. Интересно, насколько это будет ресурсоёмко?

Получается, надо ввести во flash-мувик строковую переменную, которой будет присвоено определённое значение. Потом PHP-скрипт на сервере будет в двоичном виде просматривать мувик и подставлять вместо вкомпилированного значения этой переменной новое, которое будет параллельно передаваться PHP-демону, скажем, через данные о сессии, хранящиеся в MySQL... хм.

Насколько осуществим такой вариант?

 

[phprus]

SevMadVic

А как в таком случае можно по максимуму усложнить задачу злоумышленнику?

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

 

[флоппик]

Помоему, если это именно мувики, проще будет отказаться от флеша, и купить серверное решение с DRM.

 

[SevMadVic]

От каких действий злоумышленника ты хочешь защититься?

Я пишу чат. Демон на PHP, клиент - на Flash. Хочу сделать его надёжным и функциональным. Позднее планирую выложить его для свободного скачивания всеми желающими.

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

В качестве аутентификации у меня служит id сессии, который передаётся flash-мувику через FlashVars при загрузке страницы с мувиком, а также который передаётся PHP-демону через MySQL. При подключении, клиент сообщает серверу id, сервер ищет данные с таким же id в MySQL. Дальше понятно...

Я хочу попытаться исключить или максимально затруднить возможность какому-нибудь товарисчу подключиться напрямую к серверу, передав тому id, и начать флудить или отсылать пачками матерные сообщения.

 

[Фанат]

С целью избавить сервер от ненужной нагрузки,

А что - такая большая нагрузка?

 

[SevMadVic]

Сразу же хочу извиниться, если разочаровал. Заговорил об аутентификации, борьбе со злоумышленниками, а тут всего-навсего чат) Но мне показалось, что данный вопрос может быть интересен не только создателям чатов, но и всем программистам, работающим со связкой PHP-Flash.

Нагрузка, вроде как, небольшая. Но причина переноса функций обработки сообщений из серверной части в клиентскую в другом: стыдно признать, но я не могу разобраться, в каком виде передаются символы кириллицы от flash-мувика PHP-демону. Во flash использую XMLSocket. К PHP-демону вместо кириллицы приходит белиберда.

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

 

[Beavis]

Автор оригинала: SevMadVic
С целью избавить сервер от ненужной нагрузки, я переложил функции обработки исходящих сообщений (проверка на мат, флуд, перевод транслитерации и пр.) на flash-клиент. То есть, сервер просто передаёт то, что ему прислал клиент другому клиенту или всем клиентам, находящимся внутри одной "комнаты".

по-моему, не самое удачное решение...

 

[SevMadVic]

Согласен. С проблемой разобрался, перенёс функции обработки сообщений обратно в PHP-демон. Всем спасибо за помощь.

 

[confguru]

Нас уже находят по слову
ave novie-nostra ales
в гугле