Proibir Engenharia Reversa .jar

O certo é vc usar Datasource !!!

Crie um arquivo contento estes parâmetros com os dados criptografados e faça a aplicação lê-lo na hora de conectar!

Se criar um arquivo criptografado a função de descriptografar vai estar em meu .jar, então com a engenharia reversa terá acesso de como descriptografar. Certo???

imagino que seu sistema crie os usuários para login em uma tabela USUARIOS e você deve estar usando então um usuário geral só para conectar a sua base de dados, como “root” ou “user” e então acaba tendo que colocar no seu .jar algo como:

connection = DriverManager.getConnection(jdbc:mysql://servidorSql/database?autoReconnect=true, root, senhaSql);

*voce pode evitar isso criando na própria database do sql um usuário/senha com acesso a base de dados e devidas permissões para cada usuário da tabela usuários assim a informação de conexão ficaria na cabeça de quem usa o sistema e não no seu código. A desvantagem é que você se sente seguro até quando você começa a ver que tem gente que cadastra senhas como 123456, ENTRAR, AAABBB, etc…

*outra solução seria fazer o seu sistema ler um arquivo criptografado colocado em um pendrive ou no pc que vai usar o sistema, se alguém pegar o cd de instalação do seu sistema com o .jar, o root/senhaSql não vão estar la. Tal pessoa teria que ter acesso ao terminal onde seu sistema esta instalado. A desvantagem é que o root/senhaSql ainda seriam acessíveis com um pouco mais de trabalho e a formula para ler o arquivo está no seu .jar.

bom… são as soluções que eu pensei porque estou com a mesma preocupação que você, se o pessoal tiver outras soluções também estou curioso.

ate+

Obrigado vicentepaf pelas ideias. Mas creio que ainda não é uma solução satisfatória. Obrigado!
Se alguém tiver outras ideias, soluções??

Lembrando que a primeira opcão, (que eu tenho pensado bastante) é justamente a que a maioria dos aplicativos inclusive todos os provedores de email usam, o que eles acrescentam é apenas um algoritmo para evitar as senhas fáceis, e aconselham mudança periódica de senha. Se o usuário não contar para ninguém sua base está “segura”. Se descobrirem apenas uma pequena parte da base de dados é comprometida, e não toda ela como no seu caso. Evitar engenharia reversa a gente sabe que é sonho, atualmente não dá, nem para java nem para linguagens nativas infelizmente.

l.albuquerque:

Obrigado vicentepaf pelas ideias. Mas creio que ainda não é uma solução satisfatória. Obrigado!
Se alguém tiver outras ideias, soluções??

Uma solução para seu problema é criar um serviço que forneça a senha do banco de dados para a aplicação.
Ou seja a aplicação cliente, solicita para este serviço remoto (pode ser um socket server) a senha do banco, assim esta senha não estará armazenada no cliente e sim em servidor remoto.
Este serviço deverá receber o próprio usuário e senha da aplicação antes de enviar a senha do BD, isto para não enviar a senha para qualquer um.
Para aumentar mais a segurança este Servidor de chaves deve fornecer uma conexão segura (SSL/TLS), seus clientes deveriam ter um certificado digital…
Com esta solução você pode alterar a senha do BD periodicamente sem seus clientes terem conhecimento.

Aplicação Cliente <----conexão segura com chave -----------> Servidor de chaves-
             |                                                                  | 
              ---------------------------------------------> Banco de DAdos <---

Depende muito do seu usuário… Client/Server tem esse risco… criptografar ajuda, mas como já foi falado, a rotina vai estar lá e no final quando a aplicação conectar, não importa nem se for um executavel criptografado, que a senha vai ser trafegada!
A primeira opção é melhor, inclusive o ideal acho uma combinação dela com webservices!

O ideal que vejo é utilizar ela, mas não atrelada ao usuário do banco de dados e sim a um esquema de permissões através de webservices. Como a conexão ao próprio banco ficará no servidor Web, esta será segura… Já o usuário só serve para o webservice, e não serve para se conectar direto no banco! E além do mais não precisa expor o banco na rede, pode bloquear acesso pelo firewall…

Cliente/Servidor é complicado mesmo…

Outra solução maluca que já adotei no passado (mas não recomendo) foi que a senha do servidor de banco de dados mudava diariamente e era preciso pegar estes dados de conexão de um serviço Web HTTPS (na época nem rest nem soap, era um get com a resposta pura)! E essa requisição precisava ser atrelada a um número token!
A partir de então a aplicação cliente se conectava ao banco de dados!
Risco existia, afinal, no momento da conexão alguem podia passar um sniffer… podia vasculhar a memória… enfim… milhares de coisas, entretanto dificultava um pouco, pois a senha não era “gravada” direto em nenhum lugar!
Combinar esta técnica com alguma técnica de criptografia pode até mesmo ser uma saida um pouco melhor (mas longe de ser segura)!

bombbr:

l.albuquerque:

Obrigado vicentepaf pelas ideias. Mas creio que ainda não é uma solução satisfatória. Obrigado!
Se alguém tiver outras ideias, soluções??

Uma solução para seu problema é criar um serviço que forneça a senha do banco de dados para a aplicação.
Ou seja a aplicação cliente, solicita para este serviço remoto (pode ser um socket server) a senha do banco, assim esta senha não estará armazenada no cliente e sim em servidor remoto.
Este serviço deverá receber o próprio usuário e senha da aplicação antes de enviar a senha do BD, isto para não enviar a senha para qualquer um.
Para aumentar mais a segurança este Servidor de chaves deve fornecer uma conexão segura (SSL/TLS), seus clientes deveriam ter um certificado digital…
Com esta solução você pode alterar a senha do BD periodicamente sem seus clientes terem conhecimento.

Aplicação Cliente <----conexão segura com chave -----------> Servidor de chaves- | | ---------------------------------------------> Banco de DAdos <---

Depois que postei que li sua mensagem!!!

kkkkkkkk

É, este problema de distribuição de chaves é comum.
Sendo resolvido com distribuição das chaves através de conexões seguras (SSL/TLS) e certificados digitais.
A questão é que quanto mais segurança mais caro sai seu projeto.
Daí a pergunta. Vale a pena?
Vai depender do tipo de sistema que estamos lidando.

Como você citou, mesmo na solução citada, um usuário mal intencionado poderia fazer um dump de memória pra localizar a senha transmitida de forma segura.

É pessoal, não fácil essa questão. Obrigado a todos.