Нет абсолютного способа достичь этой цели. Если у вас есть веб-служба, которая использует общие учетные данные (один из которых входит в приложение), то можно будет выполнить обратный инжиниринг этих учетных данных. В конечном счете невозможно гарантировать, что клиент, работающий на другом компьютере, является «вашим» клиентом.
Было много обсуждений этого. Это не безнадежно, только невозможно решить 100% (или даже 90%). Простой общий секрет через SSL остановит большинство ваших злоумышленников, не нанося вреда вашим пользователям и не тратя много денег на разработку. Это запутывание, а не безопасность, но дешевый и «в основном эффективный» гораздо лучше, чем дорогой и «в основном эффективный».
Если у вас очень дорогой продукт, он может потребовать более агрессивных (дорогих) решений. Все эти решения включают одну из двух вещей:
- Аутентификация пользователя, а не программы, или
- Постоянная бдительность, отслеживание новых атак и реагирование с исправлениями, исправляющими их.
Последнее очень дорого и никогда не заканчивается. Убедитесь, что оно того стоит.
Некоторые другие полезные обсуждения:
РЕДАКТИРОВАТЬ Я хотел бы отметить одну вещь, касающуюся моего упоминания о «общем секрете через SSL». Помните, что если вы не проверите сертификат, вы подвергаетесь очень легким атакам «человек посередине». Легкодоступные прокси, такие как Charles , могут сделать это. Лучший способ - убедиться, что возвращаемый сертификат SSL подписан вашим корневым сертификатом, а не просто «любым доверенным сертификатом». Вы можете перенастроить сертификаты, которым доверяет ваше приложение, с помощью SecTrustSetAnchorCertificates(). iOS5: PTL описывает эту технику в главе 11 (стр. 221). Я также обернул это в библиотеку под названием RNPinnedCertValidator .
Другим хорошим уровнем является внедрение системы «вызов-ответ», в которой сервер проверяет подлинность того, что клиент имеет общий секрет, даже не передавая его по сети. Статья в Википедии, посвященная аутентификации с резонансным вызовом , содержит хорошее объяснение алгоритма.