Безопасная Коммуникация Между iPhone и Сервером?

Вы можете предоставить механизм быстрого ответа на запрос, если у вас есть контроль над API XML.

Сгенерируйте число и включите его в свое приложение и на сервер. Используйте это как начальное значение для srand () как на клиенте, так и на сервере.

Пусть запрос от клиента включает что-то вроде:

<handshake id="123">12312931</handshake>

там id означает сгенерированное 123 случайное число, а 12312931 - это значение после вызова rand ( ) 123 раза. Значение 123 также должно быть случайно сгенерированным числом (сгенерированным с другим начальным числом!).

Это не надежный ответ на вызов, но он простой и эффективный, и не полагается ни на что, кроме базового Набор библиотек ANSI C.

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

Доступ к вашей веб-службе через https с аутентификацией.

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

Вы можете использовать какую-то подпись, чтобы убедиться, что это действительно ваше приложение, выполняющее вызов, вы вычисляете подпись как на стороне сервера, так и на стороне приложения, только если они совпадают, служба вернет с ответом на запрос. Обычно сигнатуры состоят из некоторого набора параметров вашей функции, за которым следует секретный ключ, затем берут его хеш-код md5 и передают его. В r equest никто не сможет найти секретный ключ, потому что он находится в хэше md5.

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

Настройте в своем приложении так, чтобы ваше приложение и сервер меняли URL-адреса время от времени, может быть, каждые две недели. Затем, если кто-то попытается получить доступ к вашему XML API, он будет вести постоянную битву за выяснение ваших URL-адресов. И в качестве вишенки на торте оставьте старые URL-адреса активными, но пусть они возвращают неверные данные. Я думаю, вы можете дать волю своему воображению и выяснить остальное здесь.