it-roy-ru.com

Лучший способ обезопасить себя REST API без аутентификации пользователя для мобильного приложения

Я делаю несколько Restful API для моего мобильного приложения.

Связь между приложением и веб-сервером должна быть выполнена в REST. Эти apis должны быть приватными, и только мое приложение должно вызывать их для успешных результатов. 

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

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

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

18
wolvorinePk

Взгляните на механизм HMAC, основанный на хэш-коде.

Ссылка на Википедию: http://en.wikipedia.org/wiki/Hash-based_message_authentication_code

Вашему клиенту (мобильному приложению) понадобится ключ API public, который идентифицирует клиент веб-службы REST, и ключ private/cryptographic. Открытый ключ API можно отправить вместе с HTTP-запросом. Это публично, и каждый может это увидеть. Однако закрытый ключ никогда не следует отправлять вместе с запросом, и его должен знать только сервер и клиент. Этот ключ используется для создания хэшированного сообщения, которое вместо этого будет отправлено на сервер. HMAC может быть сгенерирован с использованием алгоритма SHA1/MD5, сообщения, которое должно быть сгенерировано алгоритмом, который знает и сервер, и клиент, и, наконец, секретный ключ. 

6
Emanuel Miranda

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

  • клиент (ваше приложение) вызовет необходимый API 
  • сервер отклонит его, но в ответ отправит строку, содержащую случайный хэш (= challenge). 
  • клиент использует эту строку в сочетании с некоторой другой строкой (= password) (уже встроенной в приложение) для создания нового хеша (= digest
  • клиент снова вызовет тот же API, но на этот раз с использованием вновь созданного дайджеста в качестве параметров аутентификации. 
  • сервер проверит этот дайджест и продолжит работу 

К вашему сведению: вышеупомянутая процедура является стандартно принятым стандартом и называется дайджест-аутентификация . Если вам нужна дополнительная помощь, просто спросите Google «Android http digest аутентификация»

4
Nasir Iqbal

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

Как насчет этого. Предположим, число A жестко закодировано в приложении. Сервер отправляет два числа B & P (P - большое простое число). Теперь вы можете вычислить фактическое число, которое будет проверено сервером, используя (A^B) % P. Ваше приложение теперь шифрует ответ (A^B)%P с помощью Server's Public Key. Сервер расшифрует его своим закрытым ключом, проверит и выдаст токен (возможно, jwt) со сроком действия. Тогда ваше приложение и сервер могут обмениваться данными с помощью этого токена. Вы можете выполнить вычисления один раз при загрузке приложения и сохранить токен для дальнейшего использования.

1
Javapocalypse

Я бы предложил создать в приложении сложный токен, состоящий из метки времени + appId + любого другого значения, которое вы можете реплицировать на сервере, и аутентифицироваться в заголовке каждого запроса, используя их. 

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

Лично я держу один запрос API открытым, который является получателем метки времени, который возвращает метку времени сервера для использования в течение 300 секунд. 

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

Посредственный хакер может взломать приложение и скопировать ваши токены

0
Ralph Melhem