Existem outras maneiras de fazê-lo. Depende de quem você acha que está vindo depois da sua string de conexão e que tipo de acesso e níveis de habilidade eles terão. A string de conexão está lá, em algum lugar, não importa como você tente escondê-la.

Sabendo que a string de conexão pode ser hackeada, sempre presumo que ela será hackeada e tomo precauções do outro lado.

Fazemos várias coisas no servidor de banco de dados para garantir que, mesmo que a string de conexão seja compactada, os dados ainda estejam seguros.

• O usuário associado à string de conexão tem praticamente zero permissões no servidor. As únicas permissões que eles têm são EXECUTE e CONTROL no SCHEMA que contém os Stored Procedures.
• O único acesso que o front-end tem é por meio de procedimentos armazenados. Nunca permitimos que o front-end envie SQL Strings.
• Os dados são mantidos em um esquema separado dos executáveis, no esquema DATA o usuário associado à string de conexão tem permissões ZERO, ele não pode olhar, cheirar ou tocar.
• Os procedimentos armazenados delegam permissões ao usuário sem login que tem permissões suficientes para executar o proc. (COM EXECUTE COMO 'usuário sem login')

Isso é tudo o que podemos fazer. Não encontramos uma maneira de impedir que a cadeia de conexão seja exposta de alguma maneira em algum lugar.

Em resposta à pergunta que Alex fez abaixo. (muito longo para comentar)

Observação. O seguinte é para o MS SQL Server, pode ser aplicado a outros sistemas DBMS, mas não posso garantir nenhum outro.

Um banco de dados contém Schema, o Schema contém objetos de banco de dados, como tabelas, exibições, procedimentos armazenados. O schmea permite que você bloqueie objetos de banco de dados, por exemplo, se você tivesse um grupo de tabelas que qualquer pessoa pudesse ver, então eles poderiam entrar em um esquema COMUM, se você tivesse informações de folha de pagamento que você precisava para proteger, você poderia colocar isso em um esquema PAYROLL. Você pode então colocar diferentes medidas de segurança no SCHEMA com base no tipo de objetos que estão dentro deles. Graficamente eles se parecem com pastas em um disco rígido e sob eles estão todos os objetos de banco de dados que eles contêm. Quando você inicia seu servidor, vários esquemas são criados automaticamente. Aquele com o qual você está mais familiarizado seria o DBO schmea. Você pode não estar ciente disso se seu administrador tiver configurado isso como seu esquema padrão.

O que fazemos é colocar todos os dados em um DATA schmea, isso significa que somente tabelas são permitidas. Então, se tivéssemos um banco de dados de folha de pagamento, as tabelas de dados entrariam em um esquema chamado dataPayroll.

Um procedimento armazenado é um bloco ou blocos de código SQL que o servidor de banco de dados pode executar quando chamado. Ele pode retornar uma Tabela de dados ou um único valor. Pense nisso como um método em C#.

Os procedimentos armazenados têm parâmetros de entrada e de retorno que são usados ​​no código SQL. Stored Procedures paramatizadas são uma forte defesa contra ataques de SQL Injection.

Nosso protocolo diz que os Stored Procedures e Views são todos armazenados em um esquema precedido por 'prog'. Portanto, no caso do banco de dados da folha de pagamento, todos os objetos que não são dados estão dentro do esquema progPayroll.

O usuário que é definido pela string de conexão só tem permissões de controle e execução no esquema 'prog'. Isso permite que eles chamem o procedimento armazenado. O usuário definido pela cadeia de conexão tem todas as outras permissões negadas. Este usuário também tem todas as permissões negadas em todos os outros lugares. No procedimento armazenado, a permissão para acessar os dados é delegada a um usuário NO LOGIN que tem permissão para recuperar os dados do esquema 'dados' usando o comando EXECUTE AS.

Não há sql no front-end. Tudo o que os programadores front-end sabem é qual é o nome dos procedimentos armazenados, os parâmetros e os tipos e valores de retorno.

Dessa forma, mesmo que o invasor consiga extrair a string de conexão do seu programa, ele ainda terá muito trabalho a fazer para poder fazer qualquer coisa em seu banco de dados, pois o usuário que ele possui só pode executar um procedimento armazenado.

Se você não tem idéia do que é qualquer uma dessas coisas, então você realmente precisa de um programador de banco de dados para configurar seu sistema para você.