Armazenamento seguro de dados secretos em um aplicativo Web do lado do cliente


11

Eu tenho esse aplicativo da Web que será toda a tecnologia do lado do cliente (HTML, CSS, JavaScript / AngularJS, etc ...). Este aplicativo da web interagirá com a API REST para acessar e modificar dados. No momento, não se sabe qual tipo de sistema de autenticação a API REST usará.

Pelo meu entendimento, qualquer tipo de sistema de autenticação de API (API Keys, OAuth 1/2, etc ...) terá certos dados que precisam ser mantidos em segredo, caso contrário, o acesso poderá ser comprometido. Para chaves de API, elas próprias precisam ser secretas, para o OAuth 2 os tokens de segredo / acesso do cliente / tokens de atualização precisam ser mantidos em segredo. Tenho certeza de que algumas das 4 chaves envolvidas no OAuth 1 precisam ser mantidas em segredo (não muita experiência com o OAuth 1). Eu tenho tentado pensar se existe uma maneira de armazenar essas coisas secretas em um aplicativo Web puro do lado do cliente, sem uma camada intermediária no lado do servidor.

Eu tenho tentado pensar sobre isso e não consigo pensar em nenhum lugar para fazer isso. Quero dizer, não posso armazená-lo em javascript, porque qualquer um pode apenas visualizar a fonte ou abrir o console e obter os dados. Não tenho 100% de certeza da segurança do localStorage e se os usuários podem acessar / modificar esses dados. Mesmo que o armazenamento local fosse seguro, as duas maneiras pelas quais consigo inserir dados não são. Uma maneira é apenas armazenar os dados no código-fonte javascript, que é a coisa mais insegura em que consigo pensar. Agora, se eu estivesse usando algo como OAuth 2, no qual as demais APIs me forneceriam os tokens, isso ainda não seria tão seguro (melhor que a primeira opção), porque esses tokens seriam retornados como texto sem formatação para quem puder ver o solicitações que o computador está fazendo podia ver.

Existe alguma maneira de um aplicativo que esteja executando o lado do cliente completamente capaz de armazenar dados secretos com segurança, sem algum tipo de camada intermediária no servidor?



O armazenamento local é específico do navegador, mas usando o Opera no Windows como exemplo, são apenas alguns arquivos de disco na pasta de perfil do usuário, portanto, é essencialmente desprotegido.
Ross Patterson

Uma maneira seria manter o segredo no servidor em um banco de dados e ter apenas application_id no cliente. Em seguida, faça a consulta oauth no servidor, para que este seja algum tipo de abordagem de proxy.
Simon Polak

Respostas:


9

Não, nunca pode ser completamente seguro. O usuário está no controle do hardware e você está tentando manter algo fora de suas mãos. Em última análise, eles podem obtê-lo através de um meio ou de outro. Como você trabalha com javascript, sua posição é MUITO pior do que um aplicativo de computador normal, pois não apenas o usuário controla o hardware, mas também a sandbox em que você está executando.

Você pode ocultar as coisas e dificultar o acesso às coisas, mas no final elas PODEM tirá-las, se tentarem o suficiente.


4
^ isso. Quão "secretos" são os dados secretos e quanto tempo e dinheiro os protegem realmente valem? Os esforços "padrão do setor" podem ser suficientes.
Davee

+1 Excelente resposta. Com um depurador JavaScript, eu posso alterar seu aplicativo, visualizar valores intermediários, etc. Se eu quiser as informações, vou obtê-las.
Ross Patterson

2

Ao projetar sistemas de segurança, é preciso sempre pensar no modelo de ameaça. " Tornar seguro " é um requisito tolo, não acionável ou verificável. " Impedir que o usuário extraia os tokens de acesso do aplicativo " é muito melhor e define os limites da solução. " Impedir que outras pessoas obtenham tokens de acesso de um usuário " também é melhor e define um espaço de solução completamente diferente. As soluções para um não necessariamente solucionam o outro ( por exemplo , o último exige absolutamente SSL se o WiFi estiver envolvido, mas isso não afetará o anterior).


0

uma opção é a API REST conceder acesso ou não com base no login do usuário; ele pode retornar um token baseado em sessão (guid, string hash, o que você quiser) que pode ser passado para as outras chamadas da API REST para autenticar o acesso

se você estiver preocupado em armazenar as informações de login do usuário na máquina cliente, não o faça, mas o usuário precisará inserir as informações da conta e da senha todas as vezes

não tão familiarizado com OAuth et al, mas não vejo nenhum motivo convincente acima para armazenar informações de autenticação persistentemente ...


Por razões, sempre há "conforto", que obviamente é o arqui-inimigo de "segurança" e "segurança".
Henon 19/04
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.