Segredos OAuth em aplicativos móveis

Ao usar o protocolo OAuth, você precisa de uma sequência secreta obtida do serviço ao qual deseja delegar. Se você estiver fazendo isso em um aplicativo Web, poderá simplesmente armazenar o segredo em sua base de dados ou no sistema de arquivos, mas qual é a melhor maneira de lidar com isso em um aplicativo móvel (ou um aplicativo de desktop)?

O armazenamento da string no aplicativo obviamente não é bom, pois alguém pode encontrá-la e abusá-la facilmente.

Outra abordagem seria armazená-lo em seu servidor e fazer com que o aplicativo o buscasse a cada corrida, nunca armazenando-o no telefone. Isso é quase tão ruim, porque você precisa incluir o URL no aplicativo.

A única solução viável que eu posso encontrar é primeiro obter o token de acesso normalmente (de preferência usando uma visualização da Web dentro do aplicativo) e, em seguida, encaminhar toda a comunicação adicional através do nosso servidor, o que acrescentaria o segredo aos dados solicitados e comunicaria com o provedor. Por outro lado, sou um noob de segurança, então eu realmente gostaria de ouvir as opiniões de algumas pessoas com conhecimento sobre isso. Não me parece que a maioria dos aplicativos atenda a esses limites para garantir a segurança (por exemplo, o Facebook Connect parece assumir que você coloca o segredo em uma sequência correta no seu aplicativo).

Outra coisa: não acredito que o segredo esteja envolvido na solicitação inicial do token de acesso, para que isso possa ser feito sem envolver nosso próprio servidor. Estou correcto?

Sim, esse é um problema com o design do OAuth que estamos enfrentando. Optamos por proxy de todas as chamadas através do nosso próprio servidor. OAuth não foi totalmente liberado em relação aos aplicativos de desktop. Não há uma solução perfeita para o problema que encontrei sem alterar o OAuth.

Se você pensar sobre isso e perguntar por que temos segredos, é principalmente para provisionar e desativar aplicativos. Se nosso segredo for comprometido, o provedor poderá realmente revogar todo o aplicativo. Como temos que incorporar nosso segredo no aplicativo de desktop, estamos meio que ferrados.

A solução é ter um segredo diferente para cada aplicativo de desktop. OAuth não facilita esse conceito. Uma maneira é fazer com que o usuário crie um segredo por conta própria e insira a chave por conta própria no seu aplicativo de desktop (alguns aplicativos do Facebook fizeram algo semelhante por um longo tempo, fazendo com que o usuário crie um facebook para configurar seus testes personalizados e porcaria). Não é uma ótima experiência para o usuário.

Estou trabalhando na proposta de um sistema de delegação para o OAuth. O conceito é que, usando nossa própria chave secreta que obtemos de nosso provedor, podemos emitir nosso próprio segredo delegado para nossos próprios clientes de desktop (um para cada aplicativo de desktop basicamente) e, durante o processo de autenticação, enviamos essa chave para o nível superior fornecedor que nos chama e volta a validar conosco. Dessa forma, podemos revogar os próprios segredos que divulgamos para cada cliente de desktop. (Emprestando muito de como isso funciona a partir do SSL). Todo esse sistema seria o prefeito de serviços da Web com valor agregado e que repassam chamadas para um serviço da Web de terceiros.

O processo também pode ser realizado sem retornos de chamada de verificação de delegação se o provedor de nível superior fornecer uma API para gerar e revogar novos segredos delegados. O Facebook está fazendo algo semelhante, permitindo que os aplicativos do Facebook permitam aos usuários criar sub-aplicativos.

Há algumas discussões sobre o problema online:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

A solução do Twitter e do Yammer é uma solução de pinos de autenticação: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

Com o OAUth 2.0, você pode armazenar o segredo no servidor. Use o servidor para adquirir um token de acesso que você move para o aplicativo e pode fazer chamadas diretamente do aplicativo para o recurso.

Com o OAuth 1.0 (Twitter), o segredo é necessário para fazer chamadas de API. Proxy de chamadas através do servidor é a única maneira de garantir que o segredo não seja comprometido.

Ambos exigem algum mecanismo que o componente do servidor saiba que é o seu cliente que está chamando. Isso costuma ser feito na instalação e no uso de um mecanismo específico da plataforma para obter um ID de aplicativo de algum tipo na chamada para o servidor.

Sou o editor da especificação do OAuth 2.0

Uma solução poderia ser codificar o segredo do OAuth no código, mas não como uma sequência simples. Oculte-o de alguma forma - divida-o em segmentos, altere os caracteres por um deslocamento, gire-o - faça uma ou todas essas coisas. Um cracker pode analisar seu código de bytes e encontrar cadeias, mas pode ser difícil descobrir o código de ofuscação.

Não é uma solução infalível, mas barata.

Dependendo do valor da exploração, alguns crackers geniais podem se esforçar para encontrar seu código secreto. Você precisa pesar os fatores - custo da solução do servidor mencionada anteriormente, incentivo para que os crackers gastem mais esforços na busca de seu código secreto e a complexidade da ofuscação que você pode implementar.

Não guarde o segredo dentro do aplicativo.

Você precisa ter um servidor que possa ser acessado pelo aplicativo por https (obviamente) e armazenar o segredo nele.

Quando alguém quiser fazer login através do seu aplicativo móvel / desktop, seu aplicativo simplesmente encaminhará a solicitação ao servidor que anexará o segredo e o enviará ao provedor de serviços. Seu servidor pode dizer ao seu aplicativo se foi bem-sucedido ou não.

Então, se você precisar obter informações confidenciais do serviço (facebook, google, twitter, etc.), o aplicativo solicitará ao seu servidor e o servidor o fornecerá somente se estiver conectado corretamente.

Não há realmente nenhuma opção, exceto armazená-lo em um servidor. Nada no lado do cliente é seguro.

Nota

Dito isto, isso só o protegerá contra clientes mal-intencionados, mas não contra clientes mal-intencionados e nem contra outros clientes mal-intencionados (phising) ...

OAuth é um protocolo muito melhor no navegador do que no computador / dispositivo móvel.

Há uma nova extensão para o Tipo de concessão de código de autorização chamado Chave de prova para troca de código (PKCE) . Com isso, você não precisa de um segredo do cliente.

O PKCE (RFC 7636) é uma técnica para proteger clientes públicos que não usam um segredo do cliente.

É usado principalmente por aplicativos nativos e móveis, mas a técnica também pode ser aplicada a qualquer cliente público. Ele requer suporte adicional do servidor de autorização, portanto, é suportado apenas em determinados provedores.

de https://oauth.net/2/pkce/

Para mais informações, você pode ler a RFC 7636 completa ou esta breve introdução .

Aqui está algo para se pensar. O Google oferece dois métodos de OAuth ... para aplicativos da Web, nos quais você registra o domínio e gera uma chave exclusiva, e para aplicativos instalados, nos quais você usa a chave "anônimo".

Talvez eu tenha encoberto algo na leitura, mas parece que compartilhar a chave exclusiva do seu aplicativo da web com um aplicativo instalado é provavelmente mais seguro do que usar "anônimo" no método oficial de aplicativos instalados.

Com o OAuth 2.0, você pode simplesmente usar o fluxo do lado do cliente para obter um token de acesso e usá-lo para autenticar todas as solicitações adicionais. Então você não precisa de um segredo.

Uma boa descrição de como implementar isso pode ser encontrada aqui: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

Não tenho muita experiência com o OAuth - mas todas as solicitações não exigem apenas o token de acesso do usuário, mas também uma chave e um segredo do consumidor do aplicativo? Portanto, mesmo que alguém roube um dispositivo móvel e tente extrair dados dele, eles precisariam de uma chave e segredo do aplicativo também para poderem fazer alguma coisa.

Sempre achei que a intenção por trás do OAuth era que todos os Tom, Dick e Harry que tivessem um mashup não tivessem que armazenar suas credenciais do Twitter de maneira clara. Eu acho que resolve esse problema muito bem, apesar das limitações. Além disso, ele não foi realmente projetado com o iPhone em mente.

Eu concordo com Felixyz. Embora o OAuth seja melhor que o Auth básico, ainda há um longo caminho a ser uma boa solução para aplicativos móveis. Estou brincando com o OAuth para autenticar um aplicativo para celular em um aplicativo do Google App Engine. O fato de você não poder gerenciar com segurança o segredo do consumidor no dispositivo móvel significa que o padrão é usar o acesso 'anônimo'.

A etapa de autorização do navegador da implementação do Google App Engine OAuth leva você a uma página onde contém texto como: "O site <some-site> está solicitando acesso à sua Conta do Google para os produtos listados abaixo"

YourApp (yourapp.appspot.com) - não afiliado ao Google

etc

Leva <some-site> do nome de domínio / host usado no URL de retorno de chamada que você fornece, o que pode ser qualquer coisa no Android se você usar um esquema personalizado para interceptar o retorno de chamada. Portanto, se você usar o acesso 'anônimo' ou o seu segredo do consumidor for comprometido, alguém poderá escrever um consumidor que engana o usuário a dar acesso ao seu aplicativo gae.

A página de autorização do Google OAuth também contém muitos avisos com três níveis de gravidade, dependendo de você estar usando chaves 'anônimas', secretas do consumidor ou públicas.

Coisas bastante assustadoras para o usuário médio que não é tecnicamente experiente. Não espero ter uma alta porcentagem de conclusão de inscrição com esse tipo de coisa no caminho.

Esta postagem do blog esclarece como os segredos do consumidor realmente não funcionam com aplicativos instalados. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

Também estou tentando encontrar uma solução para autenticação OAuth móvel e armazenando segredos dentro do pacote de aplicativos em geral.

E uma idéia maluca me atingiu: a idéia mais simples é armazenar o segredo dentro do binário, mas ofuscado de alguma forma, ou, em outras palavras, você armazena um segredo criptografado. Então, isso significa que você precisa armazenar uma chave para descriptografar seu segredo, o que parece ter nos levado a um círculo completo. No entanto, por que não usar apenas uma chave que já esteja no sistema operacional, ou seja, é definida pelo sistema operacional e não pelo seu aplicativo.

Então, para esclarecer minha ideia, é que você escolha uma string definida pelo sistema operacional, não importa qual. Em seguida, criptografe seu segredo usando essa sequência como chave e armazene-a no seu aplicativo. Em seguida, durante o tempo de execução, descriptografe a variável usando a chave, que é apenas uma constante do SO. Qualquer hacker que espreite seu binário verá uma sequência criptografada, mas nenhuma chave.

Isso vai funcionar?

Aqui, respondo a maneira segura de armazenar suas informações oAuth em aplicativos móveis

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securitystoringoauthkeysiniosapplication

O Facebook não implementa o OAuth estritamente (ainda), mas eles implementaram uma maneira de você não incorporar seu segredo no seu aplicativo para iPhone: https://web.archive.org/web/20091223092924/http://wiki. developers.facebook.com/index.php/Session_Proxy

Quanto ao OAuth, sim, quanto mais eu penso sobre isso, estamos um pouco entupidos. Talvez isso conserte.

Nenhuma dessas soluções impede um determinado hacker de farejar pacotes enviados de seu dispositivo móvel (ou emulador) para exibir o segredo do cliente nos cabeçalhos http.

Uma solução seria ter um segredo dinâmico composto por um carimbo de data / hora criptografado com uma chave de criptografia bidirecional e algoritmo privados. O serviço descriptografa o segredo e determina se o carimbo de data / hora é de +/- 5 minutos.

Dessa maneira, mesmo que o segredo seja comprometido, o hacker poderá usá-lo apenas por um período máximo de 5 minutos.

Como outros já mencionaram, não deve haver problema real em armazenar o segredo localmente no dispositivo.

Além disso, você sempre pode confiar no modelo de segurança baseado no UNIX do Android: somente seu aplicativo pode acessar o que você escreve no sistema de arquivos. Basta escrever as informações no objeto SharedPreferences padrão do seu aplicativo.

Para obter o segredo, seria necessário obter acesso root ao telefone Android.