Ограничить REST API только для мобильных приложений - предлагаемый метод

Question

Я много читал, что вы не можете ограничить свой Public REST API только своим мобильным приложением, но у меня есть идея, и мне нужны мнения по этому поводу:

Метод ключа переменной приложения

Мобильное приложение

1. Получить IP-адрес текущего соединения
2. Используйте секретный алгоритм для генерации хешированного AppKey из IP-адреса.
3. Отправляйте AppKey с каждым запросом API

Сторона сервера

1. Проверьте IP-адрес входящего запроса
2. Генерация AuthKey из этого IP-адреса с использованием того же секретного алгоритма.
3. Сравните AuthKey с AppKey, если они совпадают, то вы знаете, что ваш Приложение говорит с вами, потому что только приложение знает секретный алгоритм.

При изменении IP-адреса:

• В мобильном приложении сгенерируйте AppKey, используя новый IP-адрес
• Серверная сторона всегда генерирует один и тот же ключ, потому что это зависит на IP адрес запроса

Основным преимуществом этого является то, что AppKey всегда будет меняться, что лучше, чем жестко закодированный 1 ключ приложения внутри кода, который может быть легко украден при чтении заголовков запроса. И даже если вы украли AppKey у пользователя, вы должны использовать тот же IP-адрес, на котором был сгенерирован этот ключ.

Есть мысли?

Answer 1

«Секретный» алгоритм должен быть в приложении… предоставлен всем.Это совсем не секрет.Безопасность от неизвестности в любом случае плоха, якобы вам не следует иметь секретных алгоритмов, потому что держать их в секрете безнадежно.В этом случае алгоритм тривиально раскрывается.

Также см. Закон Шнайера.:)

Редактировать:

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

Но затем рассмотрим два возможных варианта:

• Этодействительно классный API, для которого все хотят создать клиент, или есть хотя бы одна такая сторона.В этом случае не нужно слишком много усилий, и алгоритм будет «сломан», то есть будет декомпилирован и реализован в другом клиенте.

• Людям все равноНесмотря на все это об этом API, для кого-то еще не очень важно создать клиент.В этом случае они, вероятно, не будут строить клиента в любом случае, и можно использовать гораздо более простые методы, чтобы другие клиенты не могли всплыть с разумным успехом.

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