подписывать запросы приложений iOS на сервер, чтобы предотвратить спам

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

Запросы из приложения iOS отправляются на наш сервер в виде POST-запросов и НЕ аутентифицируются каким-либо образом.

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

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

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

Я не ищу идеального решения - решение, которое легко реализовать на 90%, определенно предпочтительнее.

Спасибо!


person aloo    schedule 14.11.2011    source источник
comment
Бонусные баллы: если есть изменения, которые можно внести ТОЛЬКО на сервере (т. е. новый код клиента не требуется, клиент по-прежнему просто отправляет UDID, сообщенный устройством) - это было бы здорово!   -  person aloo    schedule 15.11.2011


Ответы (1)


Я бы решил эту проблему, взяв сообщение, посолив его секретным ключом, известным только вашему приложению, и, возможно, добавив имя пользователя и UUID, а затем хешировав их с помощью SHA-1. Если хэш представлен вместе с данными, то он будет действовать как цифровая подпись, и вы можете быть достаточно уверены в подлинности сообщения.

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

Другим подходом было бы создание пары закрытый/открытый ключ pgp при регистрации, но для решения этой проблемы требуется много работы.

person Tim Howland    schedule 14.11.2011