String de conexão ao banco exposta

Pessoal, gostaria da opinião de vocês, tenho uma classe que faz a conexão com o banco de dados, não sei o que me deu na cabeça mas eu abri o .class num editor hexa. Olhando o código (em ascii não hexa), eu vi o driver utilizado, o IP do banco, usuário e senha para conectar. Eu vejo isso como falha de segurança, pois eu abri o arquivo como curioso e encotrei essa informação, algum mal intencionado pode ter a mesma curiosidade e f**** o sistema. Vocês fazem algum esquema especial de conexão? Por favor, postem suas opiniões e vamos ver quem está no mesmo barco que eu.

Vc pode cripotografar esses dados.

Você tem que ver que você teve acesso aos jars do sistema. A não ser que alguém invadisse o servidor de aplicações e conseguisse abrir os jars e ver os dados para conexão com o banco seria uma falha, mas não do sistema, e sim do serivdor. Uma solução seria usar obsfucadores no seu código de conexão ao banco para embaralhar o código.

Eu colocaria este tipo de coisa em um arquivo .properties na configuração de um ds.

Heee há pois é :smiley:

Isto é normal de Strings, ficarem expostas numa visualização em ascii, até com exes acontece isto, e com os ficheiros .class ainda é mais facil, pois se tentar esconder de alguma forma num exe tem q se usar um desasembler e manjar muito de assembler para conseguir descobrir, agora com um .class tem varios reverses que até pegam os comentários no meio do código java… o código fica a 100%…

Com isto chegamos a conclusão que nenhuma solução creio eu será 100% segura… :slight_smile:

Pode-se fazer é… encriptar os dados num arquivo ou numa string com DES, e a chave guardar num array de Chars, para não ficar numa sequencia em string…

Mas para ser mais simples talvez se meter apenas num array de chars, já dá pro gasto… ao menos nao fica tão visível… que encriptar com DES, se alguem descodificar o .class vai pegar na mesma…

:?

Soares,

Estou estudando Java. Pelo que vi, o .class não é seguro.
Fácil de fazer engenharia reversa.
Tente restringir o usuário no próprio BD (usuário só para Insert, Update…), usando LDAP ou MAC da Máquina usuário. Acredito que com isso dá uma segurança extra.

Se é uma aplicação web, nem esquenta, que não vai parar na mao do cliente (Em teoria :twisted: )

Agora se é uma aplicação em dektop não vai ter muito por onde fugir, que sempre vai ter um jeito de descobrir :lol:

Creio que a melhor solução numa aplicação desktop, é ter um programa como server das conecções a base de dados, onde as querys e tudo mais fique neste programa, e ai os clientes apenas passam um ID e e os parametros das querys, e o programa no server executa fazendo ele a coneção com a base de dados, e apenas retorna o resultado das querys ao cliente, assim o cliente não acessa diretamente a base de dados… já fica menos pior :roll:

Usa RMI :smiley: deixa toda esta parte no server :slight_smile:

Proteger senha é a coisa mais complicada do mundo :smiley:

1º vc pode misturar tudo q já foi sugerido: armazenar em array de char, encriptar, colocar a parte de acesso ao database numa área mais segura, criar mais de 1 usuário e distribuir as permissões.

Eu tb sugiro q em vez de colocar esses dados estáticos no programa, vc coloque num arquivo separado, tipo texto simples, properties ou XML, encriptar esse arquivo, colocar tudo em unix dando permissão de acesso só pro usuário da aplicação e pro root. Daí sempre q preciso seu programa lê esse arquivo pra pegar os dados. Parece q tb tem um tal de kerberos q melhora a segurança.

Parece que encriptar um arquivo com esses dados é uma boa solução, valeu pelas respostas.