Conexão segura com o banco de dados?

Como assim dados do usuário no código? Isso deve ficar no banco de dados do usuário.

Se você faz acesso direto ao banco de dados de forma remota, não há outro jeito, vai ter que manter a senha do usuário do DB no teu programa. Liberar acesso ao DB de forma remota não é uma boa prática.

Uma alternativa é criar um gateway de acesso ao DB, uma aplicação WEB por exemplo, e lidar com autenticação/autorização lá.

Você pode criptografar o seu código dá uma olhada no site abaixo:

Bom dia!
São os dados de acesso ao banco.

Bom dia!
Tem algum material sobre isso para me passar?

Bom dia!

Não queria usar ofuscadores de código.
Deve ser um atraso na manutenção do código em caso de escalabilidade.

Entendi, achei que fosse informação do usuário final. Você não pode simplesmente deixar a senha do banco criptografada no arquivo de configuração?

Mas não iria precisar de uma classe com o algoritmo para descriptografar na hora de conectar ao banco?
Se essa classe sofresse engenharia reversa, poderia ser um fracasso.

Sou iniciante, não sei se o que estou dizendo é correto.
Pode me dar uma luz @javaflex ?

A chave de criptografia pode ficar em outro lugar, dentro do banco de dados por exemplo. Por meios normais, só quem sabe a senha do banco vai conseguir acessar a tabela onde está a chave.

Pode me falar mais sobre isso?
Criaria uma tabela com campos que armazenassem as variáveis necessárias para calcular a chave?
Mas como acessaria essa tabela sem a senha do banco?
De qualquer forma preciso acessar o banco antes de obter os dados, não?

O acesso direto da aplicação ao banco de dados de forma remota, por si só, é uma potencial falha de segurança e deve ser evitado.

Se você vai distribuir tua aplicação para usuários diversos, cada um vai ter credenciais para acessar a aplicação, não é? Utilize isso para fazer autenticação/autorização, na camada de aplicação/serviço (um web service, por exemplo) e não no DB. Dessa forma, você não precisa colocar as credenciais do DB na aplicação de forma nenhuma.

Se você não vai distribuir isso, ou então é apenas para uso interno (ou de pessoas que você confia), pode deixar as credenciais na aplicação mesmo.

Não importa a gambiarra que você fizer, sempre vai ter um jeito de descobrir as credenciais e conectar diretamente no banco. Você pode apenas complicar esse processo, mas não impedi-lo completamente.

Se você quer fazer o acesso direto ao DB, você precisa que cada usuário do teu programa tenha um usuário no DB, por questões de logging, segurança, etc.

Parte pra uma camada de serviço e resolve isso lá, muito mais fácil.

FJ-21

Tem razão, você vai cair no mesmo problema. Na época que trabalhava com aplicação desktop client/server isso ficava na aplicação mesmo, mas como era Delphi não tinha essa fragilidade do Java que pode ser facilmente descompilado.

A melhor maneira de fazer isso que com um servidor web, assim você poderia criptografar as informações com o padrão SSL. Eu acho complicado de fazer, então para facilitar leia o livro Web Service Restful do Ricardo R. Lecheta.

Prezados, mais uma vez agradeço pela atenção dispensada.
Estou indagando sobre, pois gostaria de fazer uma aplicação desktop independente de hospedagens na internet. Algo bem free mesmo.
Mas ao que parece, esse nível de segurança em Java eu só conseguiria envolvendo web né?

Não só em Java, mas em qualquer linguagem de programação que você utilizar. É um problema inerente desse tipo de acesso que você está tentando.

Você vai ter que hospedar o banco de dados em algum lugar, não é?

Sabe @javaflex, gosto muito da área desktop, já pensei em migrar pra Delphi.
O único empecilho é que Delphi exige licenças para a IDE e demais itens.
Mas já tive a oportunidade de entrar em contato com a linguagem e gostei muito.

Mas a nível de discussão, o que entrava o Java de fazer uma melhoria em sua linguagem de forma a não permitir essa engenharia reversa?
Só faltou isso pra ser uma enorme potência, se tratando da proteção ao código fonte…

Olha, ao que parece você está querendo fazer um banco de dados online para várias pessoas acessarem. E as pessoas só podem acessar se tiverem um conta. Então sim, é necessário um webservice.

No caso, estava pensando em testes como um redirecionamento de ip com um domain estático (NO-iP).
Algo do tipo.
Iria hostear na minha própria maquina.

Então você pode hospedar o web service na sua máquina também.

Instalando o Tomcat né?
Já fez algo do tipo? Em nível de testes mesmo.

Não precisa fazer a aplicação web usando Java. Qualquer linguagem de programação que consiga abrir um socket provavelmente tem bibliotecas para fazer aplicações WEB. Você pode fazer em JavaScript com NodeJS, por exemplo, que vai ser muito mais simples.

Caso você queira fazer em Java, usando Java EE, pode ser o Tomcat sim, como qualquer outro container de aplicação (WildFly, WebSphere, Glassfish, etc.).

É bem simples fazer uma aplicação web em Java. Todos os frameworks (Java EE, Spring, VRaptor, etc.) abstraem as requisições web em objetos Java. Você só precisa implementar a lógica de negócio/acesso aos dados.

Estou “correndo” da tecnologia web, porque sou iniciante em Java SE ainda.
Acho que pra sair do SE, ainda preciso me aprofundar em Collections e Multitrheading.

Já tenho o básico de HTML5 e CSS, inclusive já desenvolvi um pequeno site, mas nada utilizando servlets e coisas do tipo.

Gostaria de ficar “expert” em SE e depois partir para o lado EE.

Acham que estou errado em relação a isso?

Gostaria de frisar que já desenvolvo utilizando padrões de projeto, encapsulamento, polimorfismo, interfaces, programação genérica e tratamento de exceções.
Mas sinto que ainda falta multithreading. Collections por enquanto só trabalho com arrayLists.

Eu acho que é mais interessante estudar em paralelo. Java SE é um negócio absurdo de grande, e tem conteúdo pra tu passar o resto da vida estudando.

Java EE não é nada alem de um conjunto de interfaces/classes abstratas que você vai usar para construir aplicações WEB. O servidor (mais conhecido como container de aplicação) vai implementar essas interfaces/classes abstratas e te entregar o comportamento desejado. Ainda é o mesmo Java SE, só que com muita coisa pronta pra ti.

Prezados, obrigado pela atenção.

Vou investir em Java EE a partir de agora.

Boa noite a todos!

Se você só quer fazer uma camada pequena de aplicação para servir de “porteiro” pro DB, não faça em Java. Vai te tomar muito tempo aprender tudo do zero, para um propósito simples. Eu diria para você pegar algo mais simples, como Python, JavaScript, Ruby ou algo do gênero.

Claro, isso se você quiser poupar tempo e esforço. Se for pra aprender mesmo, vai fundo que vale a pena.

Também pode usar RMI e abstrair o acesso remoto, se quiser fazer em Java mesmo.

Obrigado pela atenção!

@Fabiobritopinto
É uma solução. Havia pensado nisso, mas estou meio com um pé atrás de usar esses ofuscadores.
Mas pela classe de conexão ser pequena, pode ser né?