Важность подписывания запросов при разработке API

[Koc]

Делаю API. Присобачил систему подписывания запросов как в контакте - сортируем параметры по ключу, конкатенируем их, добавляем секретный ключ и делаем md5 от этой строки. Ее добавляем как sig к query string.

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

Какие цели я преследовал, добавляя это подписывание: удостовериться, что запросы идут от определенных appId. Что бы в случае, если с одного и того ж приложения будет слишком много запросов я мог забанить именно это приложение (сначала баним юзера а уж потом приложение). Что бы можно было отслеживать посещаемость определенного приложения. В этом случае они предлагают просто слать appId.

Как быть?

 

[tz-lom]

Koc
любую защиту можно взломать,другое дело что никто этим заниматься не будет
хотя можете добавлять ассиметричное шифрование,его ломать будут долго,другое дело нужна ли вам эта доп нагрузка

 

[fixxxer]

digest authentication?

 

[Koc]

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

та не, это сложно)

почему контакт использует такой тип подписи запросов?

 

[Raziel[SD]]

та не, это сложно)

почему контакт использует такой тип подписи запросов?

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

 

[Sokil.Dmytro]

Ман по аутентификации мобильного приложения в контакте
http://vkontakte.ru/developers.php?id=-1_21239305&s=1

Подпись формируется в виде суммы параметров запроса и некоего секретного слова.
Секретное слово получается после того как юзер ввошел в контакт, слово не вкомпилено и по сему разное для разных сессий.
Тоесть кулхацкеру все равно надо знать логин пароль чтобы что-то нахимичить. А значит задача при наличии HTTPS опять сводится к паяльнику. Без HTTPS (как у контакта) в принципе можно заморачиваться сканом нешифрованного макдональдсовского вай-фай ефира и прочими хулхацкерскими делами, о чем есть давно уже подтверждения на ютубе

Флеш-аппликухи тоже получает параметры доступа сессионно. Их можно в открытом виде смотреть в аттрибуте flashvars тега EMBED, грузящего апликуху

У Котерова есть готовая подписывалка параметров HTTP_UrlSigner.
А еще давно существует OAuth, не даром его пользуют твиттер и фейсбук

Это скорее защита от дурака, имхо.

Если бы это была защита от дурака, контакт бы утонул в океане спама, а так он пока просто захлебывается

 

[zerkms]

Зашёл в тред написать об OAuth, но его уже упомянули.

Разве что хотелось бы немного уточнить, что фейсбук использует несколько модифицированную версию Oauth v2 (которая пока только черновик), а твиттер - модифицированную Oauth v1

 

[zerkms]

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

Вот поэтому и должно быть два ключа - для пользователя и для приложения.

 

[Raziel[SD]]

Ман по аутентификации мобильного приложения в контакте

Если бы это была защита от дурака, контакт бы утонул в океане спама, а так он пока просто захлебывается

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

 

[Koc]

сессия юзера динамически создается когда он логинится

 

[HraKK]

OAuth не предназначена для генерации сессии. Поэтому все равно надо 1 раз логинется с помощью OAuth а потом создавать свою signature и ее юзать.

 

[Sokil.Dmytro]

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

я кажется так и написал