Лучшая практика для обнаружения приложения для iPhone только доступ для веб-сервисов?

Вот расширение предложения Даниэля.

Имейте общий секрет, известный серверу и клиенту. Скажите длинную случайную строку.

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

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

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

Вероятно, наиболее безопасным решением является цифровая подпись запроса. Вы можете хранить секретный ключ в приложении iPhone и использовать его для подписи запросов, которые затем можно проверить на стороне сервера. Это позволяет избежать отправки ключа / пароля на сервер, что позволило бы кому-то перехватить его сетевым сниффером.

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

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

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

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

The problem with most if not all solutions here is that they are rather prone to breaking once you add proxies in the mix. If a proxy connects to your webservice, is that OK? After all, it is probably doing so on behalf of an iPhone somewhere - perhaps in China? And if it's OK for a proxy to impersonate an iPhone, then how do you determine which impersonations are OK?

A very cheap way to do this could be getting the iPhone software to send extra data with the query, such as a long password string so that someone can't access the feed.

Someone could reverse engineer what you have done or listen to data sent over the network to discover the password and if bandwidth limitations are the reason for doing this, then a simple password should be good enough.

Of course this method has it's problems and certificate based authentication will actually be secure, although it will be harder to code.

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

Я также спросил его о возможности использования push-уведомлений как средства для этого, и он подумал, что это очень хорошая идея. Основная идея заключается в том, что при первом доступе на вашем сервере будет запускаться push-уведомление, которое будет отправлено на iPhone пользователя. Поскольку ваше приложение открыто, оно вызовет метод application: didReceiveRemoteNotification: и доставит полезные данные по вашему выбору. Если вы сделаете эту полезную нагрузку одноразовым идентификатором, то ваше приложение сможет отправить одноразовый идентификатор при следующем запросе, и вы завершили круг.

После этого вы можете сохранить UDID и отклонить любые запросы, содержащие непроверенные UDID.

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

Я полагаю, вы просто хотите отговорить от использования вашего сервиса. Очевидно, вы не настроили безопасность своего приложения.