Small API Security Best Practice

Question

Я в ситуации, когда я делаю приложение iPhone и RESTful API (через php-скрипт) для связи с базами данных хранилищ отдельных клиентов.

В настоящее время я вручную настраиваю отдельные веб-серверы с самоподписанным сертификатом. Создайте пользователя со специальным длинным случайным паролем (он жестко закодирован в приложении). Настройте свой веб-сервер так, чтобы мой php-скрипт требовал Basic Authentication и предоставлял только доступ к определенному пользователю.

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

Есть ли что-то не так с этой моделью?

Answer 1

Любой пользователь может легко зафиксировать имя пользователя и пароль, указав приложение на свой сервер с помощью базовой настройки аутентификации и самозаверяющего сертификата.

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

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

С именем пользователя и паролем они могут получить доступ к вашему API на своих условиях, конечно, в то время как кто-то платит за учетную запись.

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

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