Segurança PasswordVault quando usada na aplicação do ecrã

A verdade é que armazenar uma senha em uma aplicação desktop, 100% de segurança simplesmente não é possível. No entanto, Você pode chegar perto de 100%.

Em relação à sua abordagem original , a PasswordVault usa o serviço Credential Locker que é construído no windows para guardar os dados de forma segura. O cacifo de credencial Está ligado ao perfil do utilizador. Portanto, armazenar os seus dados através de PasswordVault é essencialmente equivalente à abordagem master password à protecção dos dados, de que falo mais pormenorizadamente. A única diferença é que a senha principal nesse caso são as credenciais do Usuário. Isso permite que as aplicações em execução durante a sessão do Usuário para acessar os dados.

Nota: para ser claro, estou a falar estritamente de armazená-lo de uma forma que lhe permita aceder ao texto simples. Ou seja, armazená-lo em uma base de dados criptografada de qualquer tipo, ou criptografá-lo você mesmo e armazenar o texto cifrado em algum lugar. Presente o tipo de funcionalidade é necessário em programas como gestores de senha, mas não em programas que apenas requerem algum tipo de autenticação. Se esta é não uma necessidade, então eu recomendo fortemente hash a palavra-passe, idealmente, de acordo com as instruções estabelecidas no esta resposta por zaph. (Mais algumas informações em [[28]}este excelente post de [[30]} Thomas Pornin ).

---

Se foruma necessidade, as coisas ficam um pouco mais complicado: se você quiser evitar que outros programas (ou usuários, suponho) sejam capazes de ver a senha de texto simples, então sua única opção real é criptografá-la. Armazenar o texto cifrado dentro do PasswordVault é opcional uma vez que, se você usar uma boa criptografia, seu único ponto fraco é alguém descobrindo sua chave. Portanto, o cifrotexto em si pode ser armazenado em qualquer lugar. Isso leva-nos à chave em si.

Dependendo de quantas senhas você está realmente tentando armazenar para cada programa exemplo, você pode não ter que se preocupar em Gerar e armazenar de forma segura uma chave em tudo . Se quiser guardar várias senhas, então poderá simplesmente pedir ao utilizador para introduzir uma senha principal , efectuar alguma salga e hashing sobre isso, e usar o resultado como chave de encriptação para todas as outras senhas. Quando for hora de descriptografia, então peça ao Usuário para introduzi-lo novamente. Se você está armazenando várias senhas, então eu recomendo fortemente que você siga com esta abordagem. É a abordagem mais segura possível. Para o resto do meu post no entanto, eu vou rolar com a suposição de que esta não é uma opção viável.

Em primeiro lugar, peço-lhe que não tenha a mesma chave para cada instalação. Crie um novo para cada instância do seu programa, baseado em dados aleatórios gerados de forma segura. Resistir à tentação de" evitar ter que armazenar a chave", fazendo com que ela seja gerada na mosca cada vez que é necessária, com base em informações sobre o sistema. Isso é tão ... seguro como hardcoding {[[0]} no seu programa. Os atacantes não demoram a perceber o processo.

---

Agora, armazená-lo é a parte mais complicada. Uma regra geral do infosec é a seguinte:

Nada é seguro quando se tem acesso físico.

Então, idealmente, ninguém o faria. Armazenar as chaves de encriptação num servidor remoto devidamente seguro minimiza as hipóteses de ser recuperado pelos atacantes. Foram escritos livros inteiros sobre o lado do servidor segurança, por isso não vou discutir isto aqui.

Outra boa opção é usar um HSM (Módulo de segurança do Hardware ). Estes pequenos dispositivos são feitos para o trabalho. Aceder às chaves armazenadas num HSM é praticamente impossível. No entanto, esta opção só é viável se você tiver certeza de que o computador de cada usuário tem um desses, como em um ambiente empresarial.

A. Net fornece uma solução de vários tipos, através do sistema de configuração. Você pode armazenar sua chave em um criptografado secção do seu app.config. Isto é frequentemente usado para proteger as cadeias de ligação. Há muitos recursos para fazer isto. Eu recomendo este post fantástico no blog, que lhe dirá a maior parte do que você precisa saber.

---

A razão pela qual eu disse anteriormente para não ir com simplesmente gerar a chave na hora é porque, como armazená-la como uma variável em seu código, você confia exclusivamente em ofuscação para mantê-la segura. O problema desta abordagem é que ela normalmente não . No entanto, às vezes você não tem outra opção. Indique A criptografia de caixa branca .

A criptografia de caixa branca é essencialmente ofuscação levada ao extremo. Ele é destinado a ser eficaz mesmo em um cenário de caixa branca, onde o atacante tanto tem acesso e pode modificar o bytecode. É o epítome da segurança através da obscuridade. Ao contrário de uma mera ocultação constante (infosec falar para a abordagem string superSecretKey) ou gerar a chave quando é necessário, caixa branca a criptografia depende essencialmente de gerar a própria cifra na mosca. [[4]}todos os documentos foram escritos nele, é difícil conseguir escrever uma implementação adequada, e a sua quilometragem pode variar. Você só deve considerar isso se você realmente realmente realmente quero fazer isto o mais seguro possível.

---

Contudo, a ofuscação ainda é ofuscante. Tudo o que pode fazer é atrasar os atacantes. A solução final eu tenho que a oferta pode parecer ao contrário, mas funciona: não esconder a chave de encriptação digitalmente. Esconde-o fisicamente. Faça o USUÁRIO inserir uma unidade usb quando for a hora de criptografia, (de forma segura) gerar uma chave aleatória, em seguida, escrevê-lo para a unidade usb. Então, sempre que é hora de descriptografia, o Usuário só tem que colocar a unidade de volta, e seu programa lê a chave fora disso.

Isto é um pouco semelhante à abordagem master password, na medida em que deixa ao utilizador a responsabilidade de manter a chave segura. No entanto, tem algumas vantagens notáveis. Por exemplo, esta abordagem permite uma chave de encriptação massiva. Uma chave que pode caber em um mero arquivo de 1 megabyte pode levar literalmente bilhões de anos para quebrar através de um ataque de Força bruta. Além disso, se a chave alguma vez for descoberta, o utilizador só tem a culpa de si próprio.

---

No resumo , veja se consegue evitar ter de guardar uma chave de encriptação. Se não conseguir, evite armazená-lo localmente a todo o custo. Caso contrário, a sua a única opção é torná-lo o mais difícil para os hackers para descobri-lo o mais possível. Não importa como você optar por fazer isso, certifique-se de que cada chave é diferente, então mesmo que os atacantes encontrar um, as chaves dos outros usuários são seguras.

A única alternativa é cifrar a senha com a sua própria chave privada guardada algures no seu código. (Alguém pode facilmente desmontar o seu código e obter a chave) e, em seguida, armazenar senha criptografada dentro PasswordVault, no entanto, a única segurança que você tem é qualquer aplicativo não terá acesso à senha.

Isto é dupla segurança, no caso de máquinas comprometidas, o atacante pode ter acesso à PasswordVault, mas não à sua senha, pois eles vão precisar de mais uma chave privada para descodificar a senha. e isso estará escondido algures no seu código.

Para o tornar mais seguro, se deixar a sua chave privada no seu servidor e expor uma API para cifrar e descodificar a senha antes de guardar no cofre, torná-la-á mais segura. Eu acho que esta é a razão pela qual as pessoas se mudaram para OAuth (armazenando o token OAuth em PasswordVault) etc em vez de armazenar senha em Cofre.

Idealmente, eu recomendaria não armazenar senha, em vez de obter algum token do servidor e salvá - lo e usar esse token para autenticacao. E guarda esse símbolo em PasswordVault.

É sempre possível forçar a segurança, com várias estratégias de encriptação e armazenamento. Tornar algo mais difícil é apenas tornar a recuperação de dados mais longa, nunca impossível. Assim, você precisa considerar o nível de proteção mais apropriado considerando o custo de execução x tempo (humano e máquina) e os aspectos de custo de desenvolvimento x tempo.

Se eu considerar estritamente o seu pedido , eu simplesmente adicionaria uma camada (classe, interface) para decifrar suas senhas. Melhor com encriptação assimétrica (e não RSA). Supondo que os outros Soft não estão acessando seus dados do programa (Programa, arquivos ou processo), isso é suficiente. Você pode usar SSH.NET ([6]} https://github.com/sshnet/SSH.NET para conseguir isto rapidamente.

Se quiser pressionar a segurança e dar um certo nível de protecção contra a engenharia binária reversa( incluindo a recuperação da chave privada), recomendo um pequeno (processo limitado) VM encriptado (como o Docker, https://blogs.msdn.microsoft.com/mvpawardprogram/2015/12/15/getting-started-with-net-and-docker/) Solução baseada em Denuvo ( https://www.denuvo.com/). a encriptação é única por cliente e máquina. Você terá que encapsular seu programa C# em um programa C/c++ (que age como um container) que fará toda a cifra-decifração na memória.

Você pode implementar sua própria estratégia, dependendo do tipo de investimento e garantia que você requerer.

No caso do seu programa ser uma infra-estrutura, você pode escolher a melhor estratégia (a única que realmente recomendo) de tudo o que é armazenar a chave privada do lado do cliente, chave pública do lado da infra-estrutura e ter decifração local, toda a senha transmitida seria, portanto, criptografada. Eu gostaria de observar que Senha e chaves são na verdade estratégias diferentes para alcançar o mesmo objetivo: verificar se o programa fala com a pessoa certa sem saber a identidade da pessoa; quero dizer isto: em vez de armazenar senhas, é melhor guardar as chaves directamente públicas.