Лучший способ защитить Private REST API без аутентификации пользователя для мобильного приложения
Я делаю несколько Restful API для моего мобильного приложения.
Связь между приложением и веб-сервером должна быть выполнена в REST. Эти apis должны быть приватными, и только мое приложение должно вызывать их для успешных результатов.
Сложность в том, что в моем приложении не требуются идентификатор пользователя и пароль, поэтому я не знаю, как я могу ограничить использование API-интерфейса rest с мобильным приложением без базовой аутентификации пользователя.
Я подумал, что одним из решений было встроить какую-нибудь строку с жестким кодом, чтобы, когда мобильное приложение будет использовать оставшийся URL, они передадут его в формате шифрования через ssl. Но я знаю, что это кажется очень плохим решением ..
Пожалуйста, предложите, что должно быть лучшим решением в такой ситуации.
Решение
Взгляните на механизм HMAC, основанный на хэш-коде.
Ссылка на Википедию: http://en.wikipedia.org/wiki/Hash-based_message_authentication_code
Вашему клиенту (мобильному приложению) понадобится общественности Ключ API, который идентифицирует клиент веб-сервиса REST и частный / криптографический ключ. Открытый ключ API можно отправить вместе с HTTP-запросом. Это публично, и каждый может это увидеть. Однако закрытый ключ никогда не следует отправлять вместе с запросом, и его должен знать только сервер и клиент. Этот ключ используется для создания хэшированного сообщения, которое вместо этого будет отправлено на сервер. HMAC может быть сгенерирован с использованием алгоритма SHA1 / MD5, сообщения, которое должно быть сгенерировано алгоритмом, который знает и сервер, и клиент, и, наконец, секретный ключ.
Другие решения
Вы правы, встроенный ключ в приложение может быть легко получен с помощью анализаторов пакетов или различных других методов. Вы можете решить эту проблему, используя следующие инструкции.
- клиент (ваше приложение) вызовет необходимый API
- сервер отклонит его, но в ответ отправит строку, содержащую случайный хэш (=вызов).
- клиент использует эту строку в сочетании с другой строкой (=пароль) (уже встроено в приложение) для создания нового хэша (=дайджест)
- клиент снова вызовет тот же API, но на этот раз с использованием вновь созданного дайджеста в качестве параметров аутентификации.
- сервер проверит этот дайджест и продолжит работу
К вашему сведению: вышеупомянутая процедура является общепринятым стандартом и называется Дайджест-аутентификация. Если вам нужна дополнительная помощь, просто спросите у Google «Android http digest аутентификация»
Вы действительно можете усложнить работу реверс-инженеров, но не можете сделать ее пуленепробиваемой, так как Насир сказал, вводя математически сложные задачи и преобразовывая вашу жестко закодированную строку соответственно.
Как насчет этого. Предположим, число A жестко закодировано в приложении. Сервер отправляет два номера B & P (P большое простое число). Теперь вы можете рассчитать фактическое число, которое будет проверено сервером, используя (A^B) % P, Ваше приложение теперь шифрует ответ (A^B)%P с Server's Public Key, Сервер расшифрует его своим закрытым ключом, проверит и выдаст токен (возможно, jwt) со сроком действия. Тогда ваше приложение и сервер могут обмениваться данными с помощью этого токена. Вы можете выполнить вычисления один раз при загрузке приложения и сохранить токен для дальнейшего использования.
Я бы предложил создать в приложении сложный токен, состоящий из метки времени + appId + любого другого значения, которое вы можете реплицировать на сервере, и аутентифицироваться в заголовке каждого запроса, используя их.
Например, вы можете создать виртуального «пользователя» в вашей базе данных, сохранить в нем deviceToken и использовать его для своего алгоритма.
Лично я держу один запрос API открытым, который является получателем метки времени, который возвращает метку времени сервера для использования в течение 300 секунд.
поэтому перед каждым запросом получите временную метку и отправьте созданный токен, скопируйте его на сервер и, таким образом, подтвердите подлинность запроса.
Посредственный хакер может взломать приложение и скопировать ваши токены