Armazenar com segurança uma senha no código do programa?

Question

Meu aplicativo utiliza a classe RijndaelManaged para criptografar dados.Como parte dessa criptografia, eu uso um objeto SecureString carregado com uma senha que é convertida em uma matriz de bytes e carregada na chave do objeto RajindaelManaged em tempo de execução.

A dúvida que tenho é sobre o armazenamento deste SecureString.Uma senha inserida pelo usuário pode ser inserida em tempo de execução e pode ser carregada "com segurança" em um objeto SecureString, mas se nenhuma senha inserida pelo usuário for fornecida, preciso definir algo como padrão.

Então, em última análise, a questão se resume a:

Se eu precisar de alguma string conhecida ou matriz de bytes para carregar em um objeto SecureString sempre que meu aplicativo for executado, como faço isso?Os dados "criptografados" são descriptografados por outro aplicativo, portanto, mesmo que nenhuma senha inserida pelo usuário seja especificada, ainda preciso que os dados sejam criptografados enquanto passam de um aplicativo para outro.Isso significa que não posso fazer com que a senha padrão seja aleatória, porque o outro aplicativo não seria capaz de descriptografá-la corretamente.

Uma solução possível que estou pensando é criar uma dll que emite apenas uma única senha, então eu uso essa senha e a executo por meio de algumas funções diferentes de hash/reorganização em tempo de execução antes de finalmente alimentá-la no objeto secureString.Isso seria seguro o suficiente?

Editar para maior clareza*:Os dados criptografados estão sendo transmitidos por meio de arquivos entre máquinas.Pense nisso como um arquivo Zip que sempre possui uma senha, uma senha padrão é assumida se nada for inserido diretamente pelo usuário.

Answer 1

Não faz sentido criptografar simetricamente com uma string codificada em seu executável.Isso apenas dará uma falsa sensação de segurança.Nenhuma quantidade de hash corrige esse esquema.

Ver esta pergunta frequente do Pidgin para o mesmo ponto em um contexto diferente.

Não estou claro por que você acha que precisa que a comunicação entre aplicativos seja criptografada.Se esta comunicação for local para a máquina, não vejo necessidade de criptografia, principalmente criptografia que não é específica do usuário.Este é um esquema DRM?

EDITAR:Se estiver sendo passado para uma máquina diferente, talvez você possa codificar um chave pública, e, em seguida, faça com que a outra máquina seja descriptografada com a chave privada correspondente.

Answer 2

Deixe-me abordar sua pergunta final primeiro.

"Isso seria seguro o suficiente?"

O único que pode responder isso é você.Ninguém aqui sabe o que significa "suficientemente seguro" no contexto da sua aplicação.

Você está criando um aplicativo para manter o diário de adolescentes?Claro, seria "suficientemente seguro".

Você está criando um aplicativo para criptografar informações ou autenticação para sistemas seguros de nível militar?Não, nem perto disso.

Você só pode contar com um tipo de segurança se pretende armazenar a senha em seu código-fonte e, portanto, executável, e isso é segurança pela obscuridade.

Se o seu problema é que você não pode ou não quer armazenar a senha no código-fonte, movê-la para uma DLL separada não resolve nada, você acabou de mover o problema para um projeto diferente.

No entanto, estou me perguntando sobre algo.Você diz "Tenho que padronizar alguma coisa".É isso?Você está tentando armazenar um valor padrão para a string de senha segura no código-fonte?Que tal "ESTA SENHA"?

Answer 3

Eric Lippert Você quer sal com isso? (postagem original do blog)

Leia também sua postagem para Use a ferramenta certa para o trabalho onde ele termina com as seguintes dicas:

0) Se você puder, simplesmente não vá lá.A criptografia é extremamente difícil de acertar e frequentemente é a solução errada em primeiro lugar.Use outras técnicas para resolver seus problemas de segurança.

1) Se o problema for um cliente não confiável, não crie uma solução de segurança que exija confiança no cliente.

2) Se você puder usar peças prontas para uso, faça-o.

3) Se você não pode usar peças prontas para uso e precisa usar um criptosistema, então não use um criptosistema que você não entende completamente.

4) Se você precisar usar um criptosistema que não entende totalmente, pelo menos não o use para resolver problemas para os quais não foi projetado.

5) Se você tiver que usar um sistema criptográfico para esquiar entre as árvores, pelo menos não permita que o cliente presumivelmente hostil escolha a mensagem que está criptografada.Escolha você mesmo o token.Se o token precisar incluir informações do cliente, limpe-o de alguma forma;exigir que seja apenas texto ASCII direto, inserir espaços em branco aleatórios e assim por diante.

6) Se você precisar permitir que o cliente escolha o token, não criptografe o token em si.Assine um hash criptograficamente seguro do token.É muito mais difícil para o invasor escolher um token que produza o hash desejado.

7) Não use o mesmo par de chaves para criptografar mensagens enviadas e para proteger mensagens recebidas.Obtenha um par de chaves para cada operação logicamente diferente que você executará.

8) Criptografe as comunicações nos dois sentidos.

9) Considere ter um mecanismo de revogação, para que, depois de saber que Eve está atacando você, você possa pelo menos revogar a licença dela.(Ou você pode revogar uma licença sabidamente comprometida e assim por diante.)

Answer 4

Este artigo sobre protegendo cadeias de conexão SQL deve ser igualmente aplicável ao armazenamento de senhas criptografadas, onde você permite que o sistema operacional lide com a criptografia da semente salgada para sua descriptografia.

Answer 5

Parece-me que talvez você devesse usar uma solução PKI em vez de criptografia/descriptografia.Se você tiver outro aplicativo que precise consumir os dados criptografados, poderá ter um par de chaves para esse aplicativo e fornecer a chave pública ao aplicativo que está fazendo a criptografia.Dessa forma, você ainda mantém seus dados seguros, mas não introduz um monte de código adicional que, em última análise, não oferece muita proteção.

Uma rápida pesquisa no Google me deu esse Artigo do Code Project que fala sobre o uso do Windows Certificate Store em .Net