Ограничение доступа к серверу для iPhone app

Question

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

Я пишу первую версию сервера в рельсах, но в какой-то момент я планирую перейти к erlang.

Я рассматриваю два подхода:

1. Генерировать «имя пользователя» (скажем, GUID) и хэш его (SHA256 или MD5) с секретом поставляется с приложением, и использовать результат как пароль". Когда клиент подключается к серверу, оба отправляются через HTTP Basic Auth over https. Сервер хэширует имя пользователя с тем же секретом и гарантирует, что они совпадают.

2. Отправка сертификата клиента с помощью приложения для iPhone. Сервер настроен так, чтобы требовать наличия сертификата клиента.

Первый подход имеет то преимущество, что он прост, низкими накладными расходами, и может быть проще запутать секрет в приложении.

Второй подход хорошо протестирован и проверен, но может быть выше накладных расходов. Тем не менее, мои знания о клиентских сертификатах находятся на «прочитайте об этом на уровне журнала Delta Airlines в полете». Сколько пропускной способности и накладных расходов на обработку данных будет иметь место? Фактические данные, передаваемые по запросу, составляют порядка килобайта.

Answer 1

Попросите пользователей вашей игры пройти аутентификацию со своей учетной записью через OAuth, чтобы разрешить им изменять состояние игры на вашем сервере.

Если вы не можете выполнить аутентификацию пользователей, вам необходимо аутентифицировать экземпляр вашего игрового приложения. Наличие учетных данных для проверки подлинности, встроенных в двоичный файл, будет плохой идеей, поскольку пиратство приложений распространено и сделает ваш метод крайне неуверенным. Мой вопрос SO how to limit Apple iPhone application piracy может пригодиться вам другими способами.

Answer 2

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

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

Answer 3

Никакой путь не является совершенным - но задача/ответ лучше, чем ключ.

Сертификат ДОЛЖЕН использовать вызов/ответ. Вы отправляете случайную строку, она шифрует ее с помощью закрытого ключа сертификата, затем вы возвращаете ее и расшифровываете ее с помощью открытого ключа.

В зависимости от того, насколько хорошо поддерживается материал на iPhone, реализация вещи будет между тривиальными и сложными.

Хорошая дорога, используемая мной, является xor. Это немного более безопасно, чем пароль, тривиальный для реализации и требует не менее часа или двух посвящений для взлома.

1. Ваше приложение имеет номер, встроенный (ключ).
2. Когда приложение подключается к вам, вы генерируете случайное число (с таким же количеством бит как ключ) и отправляете его на телефон
3. Приложение получает номер, xor его с ключом и отправляет результат назад.
4. На сервере вы получите возвращенный результат с ключом, который должен привести к исходному случайному числу.

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

В любом случае, xor - это взлом, но он работает в случаях, когда отправка пароля - это немного для взлома.

Разница между xor и открытым ключом заключается в том, что xor EASILY обратима, просто контролируя успешную беседу, открытый ключ (теоретически) не обратим без значительных ресурсов и времени.