Como os aplicativos populares autenticam as solicitações do usuário de seu aplicativo móvel para o servidor?


118

Digamos que eu tenha um aplicativo Android que se conecta a uma API .Net para receber / configurar dados. A confusão que eu tenho é sobre como se inscrever / fazer o login do usuário pela primeira vez e como autenticá-lo toda vez que ele fizer uma solicitação à API.

  • Se eu apenas usar a autenticação baseada em nome de usuário / senha, eles não serão seguros o suficiente?
  • E não consigo salvar esse nome de usuário / senha no dispositivo por razões de segurança, é claro?
  • Devo emitir um GUID para cada usuário no momento da inscrição, salvá-lo em seu dispositivo e recuperá-lo sempre durante uma solicitação de API?

Quais outros padrões estão disponíveis e quais são mais eficientes e seguros, eu só preciso de um fluxo de processo para isso. Alguém pode me dizer qual método os aplicativos Android famosos, como Facebook, FourSquare ou Twitter, usam para autenticar cada solicitação proveniente de seu aplicativo móvel para seu servidor?

Desculpe antecipadamente se essa não for uma informação pública.

Respostas:


48

Imagino que eles usem um sistema de segurança baseado em "tokens", de modo que a senha nunca é armazenada em lugar nenhum, apenas usada na primeira vez para autenticação. Portanto, o aplicativo inicialmente posta o nome de usuário / senha (por SSL) e o servidor retorna um token que o aplicativo armazena. Para as tentativas de sincronização subsequentes, o token é enviado primeiro, o servidor verifica se é válido e permite que outros dados sejam postados.

O token deve ter uma expiração para que o servidor possa solicitar novamente uma tentativa de autenticação.

Se você conectar o adaptador de sincronização de dentro do Android Framework, isso dará a você a capacidade de sincronizar e autenticar tudo sob o capô.

http://developer.android.com/training/sync-adapters/creating-sync-adapter.html

Se você verificar as contas em Configurações no seu dispositivo, verá o que quero dizer.


19

Basicamente, esses famosos usam o protocolo OAuth (1) / framework (2). Mesmo que tenha que ser um padrão, cada um deles teve diferentes implementações deste protocolo / estrutura. Portanto, temos que ter muito cuidado quando se trata de integração.

Exemplo: o Dropbox ainda usa OAuth 1 e recentemente surgiu com o suporte para OAuth 2.

Voltar para a resposta, Como, declarou Peterpan, é uma forma de autenticação baseada em tokens que é única e fora da equação. Esses tokens expiraram ou esse poder é fornecido ao desenvolvedor em alguns casos.

O interessante por trás disso é que, o escopo de acesso ao recurso pode ser definido em vez de permitir que o aplicativo cliente mantenha os nomes de usuário, senhas o que é perigoso.

Esta é a ilustração básica de como isso funciona.

insira a descrição da imagem aqui

Vou atualizar a resposta depois de obter mais detalhes sobre isso, já que estou trabalhando nessa área atualmente :)


13

Se eu apenas usar a autenticação baseada em nome de usuário / senha, eles não serão seguros o suficiente?

Não, porque você está apenas identificando a OMS está a aceder ao servidor de API, mas não o QUE está acessando.

A diferença entre QUEM e O QUE é acessar o servidor API

Para entender melhor as diferenças entre o QUEM e o QUE está acessando um servidor API, vamos usar esta imagem:

Ataque de homem no meio

O Canal de Comunicação Pretendida representa o aplicativo móvel sendo usado como você esperava, por um usuário legítimo sem quaisquer intenções maliciosas, usando uma versão não manipulada do aplicativo móvel e se comunicando diretamente com o servidor API sem ser atacado no meio.

O canal real pode representar vários cenários diferentes, como um usuário legítimo com intenções maliciosas que pode estar usando uma versão reempacotada do aplicativo móvel, um hacker usando a versão original do aplicativo móvel, enquanto o homem no meio o ataca, para entender como a comunicação entre o aplicativo móvel e o servidor de API está sendo feita para poder automatizar ataques contra sua API. Muitos outros cenários são possíveis, mas não iremos enumerar cada um aqui.

Espero que agora você já tenha uma ideia do porquê o QUEM e O QUÊ não são os mesmos, mas se não, ficará claro em um momento.

O WHO é o usuário do aplicativo móvel que podemos autenticar, autorizar e identificar de diversas formas, como por exemplo, usando fluxos OpenID Connect ou OAUTH2.

OAUTH

Geralmente, o OAuth fornece aos clientes um "acesso delegado seguro" aos recursos do servidor em nome do proprietário do recurso. Ele especifica um processo para que os proprietários de recursos autorizem o acesso de terceiros aos recursos do servidor sem compartilhar suas credenciais. Projetado especificamente para funcionar com Hypertext Transfer Protocol (HTTP), o OAuth permite essencialmente que tokens de acesso sejam emitidos para clientes de terceiros por um servidor de autorização, com a aprovação do proprietário do recurso. O terceiro então usa o token de acesso para acessar os recursos protegidos hospedados pelo servidor de recursos.

OpenID Connect

OpenID Connect 1.0 é uma camada de identidade simples sobre o protocolo OAuth 2.0. Ele permite que os Clientes verifiquem a identidade do Usuário Final com base na autenticação realizada por um Servidor de Autorização, bem como obtenham informações básicas de perfil sobre o Usuário Final de maneira interoperável e semelhante a REST.

Embora a autenticação do usuário possa permitir que o servidor API saiba QUEM está usando a API, ela não pode garantir que as solicitações tenham se originado do QUE você espera, a versão original do aplicativo móvel.

Agora precisamos identificar o QUE está chamando o servidor API, e aqui as coisas se tornam mais complicadas do que muitos desenvolvedores podem pensar. O QUE é a coisa que está fazendo a solicitação ao servidor API. É realmente uma instância genuína do aplicativo móvel ou é um bot, um script automatizado ou um invasor mexendo manualmente com o servidor de API, usando uma ferramenta como o Postman?

Para sua surpresa, você pode acabar descobrindo que pode ser um dos usuários legítimos usando uma versão reempacotada do aplicativo móvel ou um script automatizado que está tentando gamificar e tirar proveito do serviço fornecido pelo aplicativo.

Bem, para identificar o QUÊ , os desenvolvedores tendem a recorrer a uma chave de API que geralmente eles embutem no código de seu aplicativo móvel. Alguns desenvolvedores vão além e calculam a chave em tempo de execução no aplicativo móvel, portanto, ela se torna um segredo de tempo de execução, em oposição à abordagem anterior, quando um segredo estático é incorporado ao código.

O artigo acima foi extraído de um artigo que escrevi, intitulado POR QUE SEU APP PARA CELULAR PRECISA DE UMA CHAVE DE API? , e que você pode ler na íntegra aqui , é o primeiro artigo de uma série de artigos sobre chaves de API.

Armazenamento de dados confidenciais no dispositivo do cliente

E não consigo salvar esse nome de usuário / senha no dispositivo por razões de segurança, é claro? Devo emitir um GUID para cada usuário no momento da inscrição, salvá-lo em seu dispositivo e recuperá-lo sempre durante uma solicitação de API?

Qualquer coisa que você salvar no dispositivo, mesmo se criptografada, pode sofrer engenharia reversa durante o tempo de execução com ferramentas como Frida ou Xposed.

Frida

Injete seus próprios scripts em processos de caixa preta. Conecte qualquer função, espie APIs de criptografia ou rastreie o código do aplicativo privado, sem a necessidade de código-fonte. Edite, clique em Salvar e veja os resultados instantaneamente. Tudo sem etapas de compilação ou reinicializações do programa.

xPosed

Xposed é uma estrutura para módulos que podem alterar o comportamento do sistema e aplicativos sem tocar em nenhum APK. Isso é ótimo porque significa que os módulos podem funcionar para diferentes versões e até mesmo ROMs sem nenhuma alteração (desde que o código original

Em um dispositivo que o invasor controla, ele também pode usar um proxy para realizar um Ataque Man in the Middle para extrair qualquer segredo que você possa usar para identificar o QUÊ ou o QUEM, conforme mostro no artigo Roube aquela chave API com um homem no ataque :

Embora possamos usar técnicas avançadas, como JNI / NDK, para ocultar a chave da API no código do aplicativo móvel, isso não impedirá que alguém execute um ataque MitM para roubar a chave da API. Na verdade, um ataque MitM é tão fácil que pode até mesmo ser realizado por não desenvolvedores.

E agora ... Estou condenado ao ponto de não conseguir proteger meu servidor API de ser abusado ?? Sem silêncio então ... a esperança ainda existe !!!

Soluções possíveis

Alguém pode me dizer qual método os aplicativos Android famosos, como Facebook, FourSquare ou Twitter, usam para autenticar cada solicitação proveniente de seu aplicativo móvel para seu servidor?

Desculpe, mas eu não tenho conhecimento suficiente sobre este aplicativo para ser capaz de elucidar você, mas posso apontar algumas outras abordagens.

Quais outros padrões estão disponíveis e quais são mais eficientes e seguros, eu só preciso de um fluxo de processo para isso.

Portanto, tudo o que é executado no lado do cliente e precisa de algum segredo para acessar uma API pode sofrer abusos de maneiras diferentes e você pode aprender mais nesta série de artigos sobre técnicas de segurança de API móvel. Este artigo ensina como as chaves API, tokens de acesso do usuário, HMAC e TLS Pinning podem ser usados ​​para proteger a API e como podem ser contornados.

Para resolver o problema de O QUE é acessar seu aplicativo móvel, você precisa usar uma ou todas as soluções mencionadas na série de artigos sobre técnicas de segurança de API móvel que mencionei acima e aceito que elas só podem dificultar o acesso não autorizado ao seu servidor API ignorar, mas não impossível.

Uma solução melhor pode ser empregada usando uma solução Mobile App Attestation que permitirá ao servidor de API saber se está recebendo apenas solicitações de um aplicativo móvel genuíno.

Atestado de aplicativo móvel

O uso de uma solução Mobile App Attestation permitirá que o servidor API saiba O QUE está enviando as solicitações, permitindo, assim, responder apenas às solicitações de um aplicativo móvel genuíno, rejeitando todas as outras solicitações de fontes não seguras.

O papel de uma solução Mobile App Attestation é garantir em tempo de execução que seu aplicativo móvel não foi adulterado, não está sendo executado em um dispositivo com acesso root, não está sendo instrumentado por uma estrutura como xPosed ou Frida, não foi atacado por MitM, e isso é obtido executando um SDK em segundo plano. O serviço em execução na nuvem desafiará o aplicativo e, com base nas respostas, atestará a integridade do aplicativo móvel e do dispositivo em execução, portanto, o SDK nunca será responsável por quaisquer decisões.

No atestado bem-sucedido da integridade do aplicativo móvel, um token JWT de curta duração é emitido e assinado com um segredo que apenas o servidor API e o serviço Mobile App Attestation na nuvem estão cientes. No caso de falha no atestado do aplicativo móvel, o token JWT é assinado com um segredo que o servidor API não conhece.

Agora, o aplicativo deve enviar com cada chamada de API o token JWT nos cabeçalhos da solicitação. Isso permitirá que o servidor API atenda a solicitações apenas quando puder verificar a assinatura e o tempo de expiração no token JWT e os recusará quando falhar na verificação.

Uma vez que o segredo usado pelo serviço Mobile App Attestation não é conhecido pelo aplicativo móvel, não é possível fazer engenharia reversa no tempo de execução, mesmo quando o aplicativo é adulterado, executando em um dispositivo com acesso root ou se comunicando por uma conexão que está sendo alvo de um ataque do Homem no Meio.

O serviço Mobile App Attestation já existe como uma solução SAAS na Approov (eu trabalho aqui) que fornece SDKs para várias plataformas, incluindo iOS, Android, React Native e outras. A integração também precisará de uma pequena verificação no código do servidor API para verificar o token JWT emitido pelo serviço de nuvem. Essa verificação é necessária para que o servidor API possa decidir quais solicitações atender e quais negar.

Conclusão

No final das contas, a solução a ser usada para proteger seu servidor API deve ser escolhida de acordo com o valor do que você está tentando proteger e os requisitos legais para esse tipo de dados, como os regulamentos GDPR na Europa.

VOCÊ QUER PASSAR A MILHAS EXTRA?

Projeto de segurança móvel OWASP - 10 principais riscos

O Projeto de Segurança Móvel OWASP é um recurso centralizado destinado a fornecer aos desenvolvedores e equipes de segurança os recursos de que precisam para construir e manter aplicativos móveis seguros. Por meio do projeto, nosso objetivo é classificar os riscos à segurança móvel e fornecer controles de desenvolvimento para reduzir seu impacto ou probabilidade de exploração.



3

Sou um novato, mas tentarei dar uma solução lógica para a questão apresentada.

Haverá duas opções, [1] Para cada URI, a autenticação http será executada, onde as credenciais inseridas do usuário serão verificadas e o usuário deverá acessar os recursos.

[2] Outra abordagem poderia ser, um usuário deve ser autenticado e em cada autenticação um token único será gerado. Usando o token gerado, o usuário deve acessar os recursos.

Embora eu não tenha certeza de qual abordagem seria mais adequada para aplicativos móveis.


3

O exemplo de autenticação é um bom lugar para começar. O Android armazena credenciais no Gerenciador de contas, você pode ver as contas nas configurações do Android. Isso armazenará tokens automaticamente, solicitará ao usuário as credenciais se expiradas ou ausentes, atualizará os tokens etc. Acho que a parte http deste exemplo está ausente ou é antiga. Estender AccountAuthenticatorActivity do Android é um grande ajudante para analisar dados serializados para o layout e de volta para a Internet.


-7

O nome de usuário e as senhas podem ser protegidos quando colocados em SharedPreferences. Usar https na conexão com um servidor também deve ser bom o suficiente.


Você pode usar SharedPreferences, mas seus dados não são criptografados por padrão. Se você está preocupado com isso, consulte, por exemplo, esta discussão no SO: stackoverflow.com/questions/785973/…
Michael Helwig

3
SharedPreferences não é um local seguro para armazenar credenciais. Qualquer dispositivo com acesso root (o que não é difícil de fazer) irá expor essas credenciais. Em vez disso, use a API de conta integrada.
Brill Pappin

O SharedPreferences também pode ser baixado de um dispositivo não enraizado, o que se não me engano é possível através do mecanismo de backup do sistema Android. Existem diferentes ferramentas para obter arquivos legíveis de um arquivo de backup do Android.
Darthmail

@BrillPappin Pergunta sobre seu comentário. As credenciais armazenadas são o e-mail e a senha do usuário, além de um token a ser enviado que representa a autenticação atual com esse e-mail. Se o usuário optar por expor suas próprias credenciais para si mesmo, por meio de enraizamento, qual será o risco?
Toolmaker Steve

O risco é duplo. 1) quaisquer dados confidenciais de fácil acesso que você deve presumir que serão acessados. Você pode não se importar realmente, mas outra pessoa pode. 2) qualquer armazenamento de uma senha é inseguro.
Brill Pappin
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.