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

Ответ 1

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

Ответ 2

Здесь разложение на предложение Дэниела.

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

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

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

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

Ответ 3

В запросе используйте цифровые подписи. Хотя довольно сложно сделать это полностью доказательством несправедливости (как и все, что касается безопасности). Это не так сложно, чтобы получить "достаточно", чтобы предотвратить злоупотребление.

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

Проблема с большинством, если не все решения здесь, заключается в том, что они довольно подвержены взлому, когда вы добавляете прокси в микс. Если прокси подключается к вашему веб-сервису, это нормально? В конце концов, вероятно, это делается от имени iPhone где-то - возможно, в Китае? И если это нормально для прокси-сервера для олицетворения iPhone, то как вы определяете, какие олицетворения в порядке?

Ответ 8

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

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