Nunca codifique senhas em seu código. Isso foi mencionado recentemente no Top 25 dos erros de programação mais perigosos :
Codificar uma conta secreta e uma senha em seu software é extremamente conveniente - para engenheiros reversos qualificados. Se a senha for a mesma em todo o software, todos os clientes ficarão vulneráveis quando essa senha for inevitavelmente conhecida. E porque é codificado, é uma grande dor de se consertar.
Você deve armazenar informações de configuração, incluindo senhas, em um arquivo separado que o aplicativo lê ao iniciar. Essa é a única maneira real de evitar que a senha vaze como resultado da descompilação (nunca compile-a no binário para começar).
Para obter mais informações sobre esse erro comum, você pode ler o artigo CWE-259 . O artigo contém uma definição mais completa, exemplos e muitas outras informações sobre o problema.
Em Java, uma das maneiras mais fáceis de fazer isso é usar a classe Preferences. Ele é projetado para armazenar todos os tipos de configurações do programa, algumas das quais podem incluir um nome de usuário e uma senha.
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
}
No código acima, você pode chamar o setCredentialsmétodo após mostrar uma caixa de diálogo solicitando o nome de usuário e a senha. Quando você precisa se conectar ao banco de dados, você pode apenas usar os métodos getUsernamee getPasswordpara recuperar os valores armazenados. As credenciais de login não serão codificadas em seus binários, portanto, a descompilação não representará um risco de segurança.
Observação importante: os arquivos de preferência são apenas arquivos XML de texto simples. Certifique-se de tomar as medidas adequadas para evitar que usuários não autorizados vejam os arquivos brutos (permissões do UNIX, permissões do Windows etc.). No Linux, pelo menos, isso não é um problema, porque a chamada Preferences.userNodeForPackagecriará o arquivo XML no diretório inicial do usuário atual, que de qualquer forma não pode ser lido por outros usuários. No Windows, a situação pode ser diferente.
Notas mais importantes: Houve muita discussão nos comentários desta resposta e em outros sobre qual é a arquitetura correta para esta situação. A pergunta original não menciona realmente o contexto no qual o aplicativo está sendo usado, então falarei sobre as duas situações nas quais consigo pensar. O primeiro é o caso em que a pessoa que usa o programa já conhece (e está autorizada a saber) as credenciais do banco de dados. O segundo é o caso em que você, o desenvolvedor, está tentando manter as credenciais do banco de dados em segredo da pessoa que usa o programa.
Primeiro caso: o usuário está autorizado a saber as credenciais de login do banco de dados
Nesse caso, a solução que mencionei acima funcionará. A Preferenceclasse Java armazenará o nome de usuário e a senha em texto simples, mas o arquivo de preferências só poderá ser lido pelo usuário autorizado. O usuário pode simplesmente abrir o arquivo XML de preferências e ler as credenciais de login, mas isso não é um risco de segurança porque o usuário já sabia as credenciais.
Segundo caso: tentar ocultar as credenciais de login do usuário
Este é o caso mais complicado: o usuário não deve saber as credenciais de login, mas ainda precisa acessar o banco de dados. Nesse caso, o usuário que executa o aplicativo tem acesso direto ao banco de dados, o que significa que o programa precisa saber as credenciais de login com antecedência. A solução que mencionei acima não é apropriada para este caso. Você pode armazenar as credenciais de login do banco de dados em um arquivo de preferências, mas o usuário poderá ler esse arquivo, pois será o proprietário. Na verdade, não existe uma boa maneira de usar esse gabinete de maneira segura.
Caso correto: usando uma arquitetura multicamadas
A maneira correta de fazer isso é ter uma camada intermediária, entre o servidor de banco de dados e o aplicativo cliente, que autentica usuários individuais e permite que um conjunto limitado de operações seja executado. Cada usuário teria suas próprias credenciais de login, mas não para o servidor de banco de dados. As credenciais permitiriam acesso à camada intermediária (a camada de lógica de negócios) e seriam diferentes para cada usuário.
Cada usuário teria seu próprio nome de usuário e senha, que poderiam ser armazenados localmente em um arquivo de preferências sem qualquer risco de segurança. Isso é chamado de arquitetura de três camadas (as camadas sendo seu servidor de banco de dados, servidor de lógica de negócios e aplicativo cliente). É mais complexo, mas realmente é a maneira mais segura de fazer esse tipo de coisa.
A ordem básica das operações é:
- O cliente se autentica com a camada de lógica de negócios usando o nome de usuário / senha pessoal do usuário. O nome de usuário e a senha são conhecidos pelo usuário e não estão relacionados às credenciais de login do banco de dados de forma alguma.
- Se a autenticação for bem-sucedida, o cliente fará uma solicitação à camada de lógica de negócios solicitando algumas informações do banco de dados. Por exemplo, um estoque de produtos. Observe que a solicitação do cliente não é uma consulta SQL; é uma chamada de procedimento remoto, como
getInventoryList.
- A camada de lógica de negócios se conecta ao banco de dados e recupera as informações solicitadas. A camada de lógica de negócios é responsável por formar uma consulta SQL segura com base na solicitação do usuário. Todos os parâmetros da consulta SQL devem ser limpos para evitar ataques de injeção de SQL.
- A camada de lógica de negócios envia a lista de inventário de volta ao aplicativo cliente.
- O cliente exibe a lista de inventário para o usuário.
Observe que, em todo o processo, o aplicativo cliente nunca se conecta diretamente ao banco de dados . A camada de lógica de negócios recebe uma solicitação de um usuário autenticado, processa a solicitação do cliente para uma lista de inventário e só então executa uma consulta SQL.