É uma boa prática definir cadeias de conexão em uma configuração da web?

Recentemente, tenho uma discussão com alguns dos meus colegas no meu trabalho, porque eles disseram que é melhor ter em um .DLL uma conexão de cadeia de caracteres criptografada. E eu disse por que simplesmente não use a conexão de string definida no web.config criptografado? é o mesmo e é melhor porque o framework de entidade, por exemplo, procura o nome da conexão na configuração web do aplicativo. Agora, quero saber de um ponto de segurança o que é melhor ou qual é a melhor prática?

Não há diferença substantiva, exceto que você precisará criar um binário se quiser fazer uma alteração na configuração se colocar em uma DLL, enquanto um administrador pode apenas modificar a configuração com ferramentas prontas para uso. se estiver na configuração. Já existe um mecanismo para criptografar seqüências de configuração e orientações adicionais no MSDN . As versões atuais do Asp.Net podem ter mecanismos alternativos, assim como algumas pesquisas adicionais antes de se comprometer com uma abordagem.

Só porque algo está em uma DLL, não a torna mais segura. Um editor de texto também pode abrir arquivos binários, ferramentas como o Reflector podem fornecer uma interface melhor para navegar em uma DLL .Net; uma DLL não fornecerá nenhuma criptografia "extra".

Não importa onde os dados criptografados estão armazenados, importa como eles são criptografados.

As seções criptografadas em um web.config normalmente são criptografadas com a API de proteção de dados , que é extremamente difícil de decifrar sem comprometer a máquina inteira. Você também pode usar um contêiner de chaves RSA, que é semelhante (difícil de tirar os da máquina).

Se você deseja armazenar a string criptografada na DLL, tudo bem, eu acho, embora não seja inerentemente mais seguro do que um web.config criptografado (qualquer um pode espiar a DLL com o Reflector ) e é obviamente mais difícil de mudar (você precisaria recompilar). Mas, novamente, o mais importante é como essa sequência criptografada foi gerada; presumivelmente você não está usando os mesmos provedores que usaria para um web.config criptografado, então o que você está usando?

Um esquema de criptografia é tão forte quanto a chave privada ou o segredo compartilhado. Se essa chave também estiver armazenada em sua montagem, é possível que você também não tenha criptografia. Se ele estiver armazenado em algum banco de dados externo, levantará a questão de como a cadeia de conexão desse banco de dados é protegida. Isso só pode realmente levar a uma segurança mais fraca em geral.

Por outro lado, se você fosse um provedor de serviços e a cadeia de conexão fosse criptografada com uma senha de usuário , isso seria mais seguro do que usar uma chave de máquina estática. Por outro lado, se você estiver usando senhas de usuário para criptografar, é muito improvável que você codifique os dados criptografados em sua montagem, pois eles precisam ser gerados e armazenados em resposta à ação do usuário (não do desenvolvedor).

Realmente, não consigo pensar em muitas situações em que a codificação embutida de uma seqüência de conexão (criptografada) na DLL é mais segura do que criptografar a seção web.config relevante. Na melhor das hipóteses, está apenas adicionando inconveniência, na pior das hipóteses, está contando com alguma segurança personalizada escrita desajeitadamente, cheia de buracos. Faça um favor a si mesmo e faça o que a Microsoft recomenda - basta criptografar seu web.config se houver dados confidenciais.

A melhor prática para o ASP.NET é colocar todas as configurações / arquivo no arquivo web.config ou no arquivo app.config (para outros tipos de projeto).

Sobre a criptografia e o motivo para usá-lo nas cadeias de conexão deve ser um caso muito especial. Como na maioria dos casos, até 99%, você não precisa criptografar as seqüências de conexão. Os aplicativos corporativos da Microsoft têm sua cadeia de conexão exposta no arquivo web.config / app.config. Eu acho que você acabou complicando a segurança.

Mais uma coisa, codificar suas cadeias de conexão é uma prática ruim. Por exemplo, não coloque nenhuma string de conexão (também conhecida como connectionstring) em uma DLL ou .aspx / .ascx / .cshtml ou code-behind.