Quão seguro é o armazenamento local?


33

A pergunta diz tudo realmente. Quero fornecer um serviço, mas não quero armazenar nenhum dos dados em um banco de dados. Com todas as notícias recentes de hackers, etc, parece-me que é melhor que os clientes tenham controle total sobre seus dados.

O problema é que os dados armazenados são potencialmente sensíveis. O que eu ia fazer era ... quando um cliente visitar o site, haveria uma pergunta perguntando 'você está em um computador pessoal ou em um computador público'? Se eles estiverem em um computador público, o site recusará o acesso.

Se eles estivessem em um computador pessoal, ele os solicitaria para definir uma senha. Todos os seus dados seriam criptografados com essa senha. Agora, obviamente, isso não é muito seguro. O método de criptografia seria em JavaScript e sua senha em texto sem formatação, portanto, presumo que seria possível para um usuário mais experiente localizar a senha no localStorage e acessar os dados.

Eu sinto que isso não é um problema muito grande. Se você estiver usando um computador pessoal, as chances disso acontecer são remotas, pois ... alguém precisaria acessar sua conta de usuário específica no computador, alguém precisaria saber sobre o site ... alguém precisaria entender localStorage e como acessá-lo. Os dados confidenciais não são aqueles que comprometam sua identidade ou muito mais. Ele apenas registra algo que a maioria das pessoas não gostaria que fosse publicado publicamente.

Então, realmente a questão é: o localStorage é seguro o suficiente?

Pergunta adicional .. quão difícil é limpar o seu localStorage? Eu não gostaria que os usuários apagassem acidentalmente seus dados.

Finalmente - vale a pena criptografar / descriptografar os dados como se você tivesse a senha, pode acessar o site.


2
O JavaScript do lado do cliente não é o melhor lugar para se fazer criptografia. Qualquer usuário experiente pode olhar para o código e invadir sua criptografia algorthim e fazê-lo para que ele realmente não faça nada e apenas aceite a senha criptografada.

Respostas:


10

Que tal simplesmente não armazenar a senha, nem mesmo no armazenamento local? Você pode usar uma função de derivação de chave para obter uma chave da senha. Com um sal e um número razoável de iterações, isso deve ser decentemente seguro.


Seria mais seguro se a senha fosse enviada ao PHP, que geraria a chave nos bastidores?
jasons

Não. A senha é fornecida no cliente primeiro. Ao enviá-lo para o servidor, você aumenta o risco de roubo. Fazer a derivação de chave em JS mantém o segredo no cliente. Em todos os casos, você deve esquecer o PW logo depois disso. Mas acho que ainda não faz sentido - veja minha resposta.

Muitos hackers são bastante inteligentes ... Use Lib bCrypt.
Eddie B #

2

O uso de JavaScript com armazenamento local é no máximo tão seguro quanto (seu servidor mais a conexão entre navegador e servidor).

Se alguém conseguir modificar seu servidor e servir arquivos JS diferentes ou modificar (enquanto estiver sendo transmitido) os arquivos JS enviados do servidor para o cliente, eles poderão fazer qualquer coisa com os dados que desejarem.

Além disso: como os dados estão no cliente, você não pode fazer nada para protegê-los. Em um servidor comum, você pode, por exemplo, restringir a frequência de acesso (por exemplo, para uma senha remota segura: apenas 1 senha é lida em 10 minutos). Tudo isso é inútil se os dados estiverem no cliente e todo o código que trabalha com os dados puder ser manipulado por um invasor.

Afinal, mesmo com o armazenamento local, você precisa proteger seu aplicativo da Web! Por que fazer as coisas no servidor (espero) seguro, então? Caso contrário, por que não usar um programa local instalado no cliente?


Você não acha que o principal problema de segurança é se o dispositivo é usado ou roubado por outra pessoa?

2

Que tal obter uma chave do servidor usado para descriptografar os dados localStorage?

Poderia funcionar assim:

  • Quando uma sessão é estabelecida, o servidor retorna uma chave.
  • Essa chave é usada para criptografar / descriptografar os dados no localStorage.
  • Quando o usuário sai da página, a chave é perdida, impedindo que outras pessoas leiam o que está no localStorage.

Isso deve permitir o acesso apenas enquanto um usuário tiver uma sessão estabelecida.


3
Porém, isso não funcionaria para acessar os dados offline (o que parece ser um caso de uso primário para localStorage). Para usar esse método offline, você precisará manter a chave.
Timothy Lee Russell

0

geralmente não é difícil limpar o armazenamento local, mas depende do navegador. Você precisa acessar as ferramentas de desenvolvedor de navegadores (firebug, webkit, etc).

pense nisso como você pensa em cookies. Você nunca deve manter dados confidenciais no armazenamento local. senhas, números de cartão de crédito, qualquer que seja.

você sempre pode implementar algum recurso para limpar o armazenamento local após x quantidade de inatividade, mas isso não resolverá um problema de segurança. É como uma sessão automática expirar. O mesmo problema se aplica: se uma pessoa sai de um computador e outra pessoa se senta antes que a sessão expire, ela pode fazer coisas.


0

Duas questões:

  1. se você armazena senhas em texto sem formatação e depois confia no fato de que provavelmente não serão encontradas, é apenas segurança através da obscuridade. Apenas armazene os dados em texto não criptografado e confie na mesma suposição (ainda não segura, mas sem falsa sensação de segurança)

  2. na maioria dos navegadores, se as pessoas limpam o cache, elas também removem o conteúdo do armazenamento local. As pessoas não esperam perder dados importantes quando limpam seu histórico e cache.

Acho que você está exagerando no significado do localStorage. Se você quiser usar um banco de dados local que joga bem com webapps você poderia dar uma olhada para CouchDB 's CouchApps .

Mas não guarde a senha.


0

Você poderia usar o javascrypt . Peça ao usuário uma senha que se torne a chave de criptografia / descriptografia

Você não precisa armazenar a senha, mas solicite-a sempre que o usuário abrir a página.
Pode ser armazená-lo, se o usuário quiser, e agora as implicações.

Mas então, para juntar-se ao comentário de stivlo, que tal:

  1. acesso a vários dispositivos
  2. cópia de segurança
  3. Esqueceu a senha
  4. limpeza de cache muito fácil

Eu acho que você deveria reconsiderar o início do raciocínio. Evitar a nuvem apenas por causa de alguns eventos recentes e sensacionais, é uma conclusão rápida.

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.