WebCrypto
As preocupações com criptografia em javascript do lado do cliente (navegador) são detalhadas abaixo. Todas essas preocupações, exceto uma, não se aplicam à API WebCrypto , que agora é razoavelmente bem suportada .
Para um aplicativo offline, você ainda deve projetar e implementar um keystore seguro.
Além: Se você estiver usando o Node.js, use a API criptográfica incorporada .
Criptografia Javascript Nativo (pré-WebCrypto)
Presumo que a principal preocupação seja alguém com acesso físico ao computador lendo o localStorage
para o seu site, e você deseja criptografia para ajudar a impedir esse acesso.
Se alguém tiver acesso físico, você também estará aberto a ataques diferentes e piores do que a leitura. Isso inclui (mas não se limita a): keyloggers, modificação de script offline, injeção de script local, envenenamento de cache do navegador e redirecionamentos de DNS. Esses ataques só funcionam se o usuário usar a máquina após ter sido comprometida. No entanto, o acesso físico nesse cenário significa que você tem problemas maiores.
Portanto, lembre-se de que o cenário limitado em que a criptografia local é valiosa seria se a máquina fosse roubada.
Existem bibliotecas que implementam a funcionalidade desejada, por exemplo, Stanford Javascript Crypto Library . Existem pontos fracos inerentes (como mencionado no link da resposta da @ ircmaxell):
- Falta de entropia / geração de números aleatórios;
- Falta de um armazenamento de chaves seguro, ou seja, a chave privada deve ser protegida por senha se armazenada localmente ou armazenada no servidor (que impede o acesso offline);
- Falta de apagamento seguro;
- Falta de características de tempo.
Cada uma dessas fraquezas corresponde a uma categoria de compromisso criptográfico. Em outras palavras, embora você possa ter "criptografia" pelo nome, ele estará bem abaixo do rigor que se almeja na prática.
Tudo isso dito, a avaliação atuarial não é tão trivial quanto "A criptografia Javascript é fraca, não a use". Isso não é um endosso, é estritamente uma advertência e exige que você compreenda completamente a exposição das fraquezas acima, a frequência e o custo dos vetores que você enfrenta e sua capacidade de mitigação ou seguro em caso de falha: criptografia Javascript, em apesar de suas fraquezas, pode reduzir sua exposição, mas apenas contra ladrões com capacidade técnica limitada. No entanto, você deve presumir que a criptografia Javascript não tem valor contra um invasor determinado e capaz que está direcionando essas informações. Alguns considerariam enganoso chamar os dados de "criptografados" quando se sabe que muitos pontos fracos são inerentes à implementação. Em outras palavras, você pode diminuir marginalmente sua exposição técnica, mas aumenta sua exposição financeira a partir da divulgação. Cada situação é diferente, é claro - e a análise de redução da exposição técnica à exposição financeira não é trivial. Aqui está uma analogia ilustrativa:Alguns bancos exigem senhas fracas , apesar do risco inerente, porque sua exposição a perdas de senhas fracas é menor do que os custos do usuário final para suportar senhas fortes.
🔥 Se você leu o último parágrafo e pensou "Um cara na Internet chamado Brian diz que eu posso usar criptografia Javascript", não use criptografia Javascript.
Para o caso de uso descrito na pergunta, parece fazer mais sentido para os usuários criptografar sua partição local ou diretório inicial e usar uma senha forte. Esse tipo de segurança geralmente é bem testado, amplamente confiável e geralmente disponível.