[OFF]: SEGURAN?A DA INFORMA?ÃO NO CÓDIGO FONTE
Gostaria de saber de vocês, independente da linguagem que vocês utilizam, qual a melhor maneira de se proteger os dados. Por exemplo quando agente cria a classe de conexão com o banco, seja ele em access, SQL server, MySql, etc...
Em uma determinada linha colocamos o servidor, o nome do banco, o nome do usuario e a senha do banco. Tá certo que depois que IDE compila a aplicação tudo vira um executável só, mas já và programas que utilizam engenharia reversa, e é aà que mora o perigo.
Portanto peço que dividam suas opiniões e deêm uma luz para os que praticam a segurança da informação de forma errada.
Minha forma de proteger, que ainda acho que não é 100%, rsrsrs! é a seguinte:
a String de conexão eu carrego de um arquivo externo, e toda ela é em Hexadecimal ou binário. Mas se um Hacker foda quiser [Ô]Fuder[Ô] com meu banco vai ser fichinha pra ele.
E aÃ? qual a forma mais confiável de se conectar ao banco???
Desde já agradeço cada opinião!
basta criar um programa que converta hexadecimal para caracteres ou mesmo sem programas pois tem tabelas ASCII character que é só ler.
a melhor forma de proteger um banco in local é colocar uma senha realmente dificil, tanto pro sistema conectar quanto para o gerenciador de MySql se houver.
Usar parametros ( coisa que nem todos fazem e não entendo porque ) Vi esses dias um tópico por aqui mesmo de um Insert ou select não lembro, cheio de gambiarras, as pessoas estão preocupadas em fazer funcionar e não em fazer funcionar da maneira correta.
Proteger a porta do MySql, separar a classe de conexão, verificar sempre onde está sendo aberta a conexão e se está sendo fechada, no caso de SGBD que tem user anonimo EXCLUIR ele, Deletar a base test, backup automatico de preferencia e que esteja ou direcionado a uma unidade em rede ou em nuvem ( eu uso minha nuvem em alguns clientes )
Em binário pode ser uma ótima escolha porém tudo que você fizer ainda sim haverá uma brecha hiauhauaheuhaeuhe
abraço
Vamos lá... vou dizer o que eu faço:
Uso também um arquivo externo. Porém uso uma criptografia, e não uma codificação (no seu quase, na base hexadecimal). Um código hexadecimal é uma coisa universal que é fácil identificar e converter para decimal, qualquer editor faz isso... E até via código é fácil obter os dados...
Sugiro que use uma criptografia simétrica AES e escolha uma chave relativamente grande. Eu uso um utilitário que criei pra criptografar a mensagem, e dentro do sistema eu deixo a minha chave.
Porém isso gera um problema, devido a engenharia reversa. O cara pode pegar meu código fonte usando uma ferramenta para descompilar.
Nessa hora, você usa um outro programa chamado de [Ô]Obsfucador[Ô]... Tem o Eazfuscator.NET, Obfuscar, etc Ele [Ô]embaralha[Ô] seu código fonte, dificultando assim a Engenharia Reversa.
Abraços!
Citação::
guardar em hexadecimal não precisa ser muito foda pra abrir ele
basta criar um programa que converta hexadecimal para caracteres ou mesmo sem programas pois tem tabelas ASCII character que é só ler.
a melhor forma de proteger um banco in local é colocar uma senha realmente dificil, tanto pro sistema conectar quanto para o gerenciador de MySql se houver.
Usar parametros ( coisa que nem todos fazem e não entendo porque ) Vi esses dias um tópico por aqui mesmo de um Insert ou select não lembro, cheio de gambiarras, as pessoas estão preocupadas em fazer funcionar e não em fazer funcionar da maneira correta.
Proteger a porta do MySql, separar a classe de conexão, verificar sempre onde está sendo aberta a conexão e se está sendo fechada, no caso de SGBD que tem user anonimo EXCLUIR ele, Deletar a base test, backup automatico de preferencia e que esteja ou direcionado a uma unidade em rede ou em nuvem ( eu uso minha nuvem em alguns clientes )
Em binário pode ser uma ótima escolha porém tudo que você fizer ainda sim haverá uma brecha hiauhauaheuhaeuhe
abraço
realmente sempre existe uma brecha cara! rsrsrsrsrsrs. Mas pelo menos agente tem q dar uma dorzinha de cabeça pros FDP dos hackers. Eu utilizo um arquivo externo, mas não disse qual o formato dele, nem qual a criptografia q ele usa. mas essa é a brecha!
Citação::
Oi meu amigo.
Vamos lá... vou dizer o que eu faço:
Uso também um arquivo externo. Porém uso uma criptografia, e não uma codificação (no seu quase, na base hexadecimal). Um código hexadecimal é uma coisa universal que é fácil identificar e converter para decimal, qualquer editor faz isso... E até via código é fácil obter os dados...
Sugiro que use uma criptografia simétrica AES e escolha uma chave relativamente grande. Eu uso um utilitário que criei pra criptografar a mensagem, e dentro do sistema eu deixo a minha chave.
Porém isso gera um problema, devido a engenharia reversa. O cara pode pegar meu código fonte usando uma ferramenta para descompilar.
Nessa hora, você usa um outro programa chamado de [Ô]Obsfucador[Ô]... Tem o Eazfuscator.NET, Obfuscar, etc Ele [Ô]embaralha[Ô] seu código fonte, dificultando assim a Engenharia Reversa.
Abraços!
Achei interessante esse Eazfuscator.NET vou dar uma pesquisada sobre ele!
E se tiver mais alguém que tem um outro jeito compartilhe aà com agente ou dê sua opinião pra mim e pros nossos colegas XLEGENDARY e DS2T
ou seja, o usuário digita a senha ele criptografa e compara com a criptografia guardada.
Mas pq não tem volta?
Por EX:
Senha = [Ô]A[Ô]
Criptografado Vira: 559aead08264d5795d3909718cdd05abd49572e84fe55590eef31a88a08fdffd = 36^64 combinações e uma numero astronomicamente grande
Senha = [Ô]JULIO[Ô]
Criptografado vira: 2a16594430d4f141927488c26ccfb7a57bc259622618706222ac170e98f48eb3
Senha = [Ô]JULIO CESAR MORAES, MORADOR DE BALNEÃRIO CAMBORIU - SC[Ô]
Criptografado vira: bfb011bc0c9f4ccd782612a45e9135790444bf51b36bdfd1874357e6b3f644f6
Se notar as tres Cryptas tem o mesmo tamanho de 64 caracteres
O invasor só consegue a senha e um super computador teria que usar tentativa e erro e poderia levar dezenas de anos.
Se o invasor pegar banco e conseguir abrir a tabela de usuários, o campo senha estará preenchido com um código indecifrável
Internamente o algorÃtimo pra crita usa a nÃvel de bits, após gerar ele corta parte da cripta, tornando a volta praticamente impossÃvel mesmo tendo o algoritimo na mão.
Isso é muito usado em empresas seguras e confiáveis que tem posse do seu numero de cartão de crédito, eles não sabem teu número pq são guardados no banco criptografados, as vezes eles guardam sem criptografar só os 4 últimos digitos do cartão.
Agora o problema é a senha que abre o banco de dados, só uma crypta com volta, mas o invasor de posse do algoritimo que gerou, pode descobrir a senha.
a maneira segura é o embaralhamento do código fonte e a segurança a nÃvel de SO. Uso nos meus sistemas SQl Server e os backups dos meu clientes são feitos na Nuvem, Uma copia no OneDrive e uma cópia do Google Drive.
Sem a senha acredito que seja difÃcil ou quase impossÃvel invadir um SQL Server ou um Oracle. o Access não tem segurança, existem programas que dizem a senha do banco.
Eu disponibilizei o programa de criptação aqui:
http://www.vbmania.com.br/index.php?modulo=detalhe&id=9375
Citação::
Eu uso criptografia Rash Sha 256bits para senhas dos usuários guardadas no banco de dados que é uma das mais seguras pois não existe volta.
ou seja, o usuário digita a senha ele criptografa e compara com a criptografia guardada.
Mas pq não tem volta?
Por EX:
Senha = [Ô]A[Ô]
Criptografado Vira: 559aead08264d5795d3909718cdd05abd49572e84fe55590eef31a88a08fdffd = 36^64 combinações e uma numero astronomicamente grande
Senha = [Ô]JULIO[Ô]
Criptografado vira: 2a16594430d4f141927488c26ccfb7a57bc259622618706222ac170e98f48eb3
Senha = [Ô]JULIO CESAR MORAES, MORADOR DE BALNEÃRIO CAMBORIU - SC[Ô]
Criptografado vira: bfb011bc0c9f4ccd782612a45e9135790444bf51b36bdfd1874357e6b3f644f6
Se notar as tres Cryptas tem o mesmo tamanho de 64 caracteres
O invasor só consegue a senha e um super computador teria que usar tentativa e erro e poderia levar dezenas de anos.
Se o invasor pegar banco e conseguir abrir a tabela de usuários, o campo senha estará preenchido com um código indecifrável
Internamente o algorÃtimo pra crita usa a nÃvel de bits, após gerar ele corta parte da cripta, tornando a volta praticamente impossÃvel mesmo tendo o algoritimo na mão.
Isso é muito usado em empresas seguras e confiáveis que tem posse do seu numero de cartão de crédito, eles não sabem teu número pq são guardados no banco criptografados, as vezes eles guardam sem criptografar só os 4 últimos digitos do cartão.
Agora o problema é a senha que abre o banco de dados, só uma crypta com volta, mas o invasor de posse do algoritimo que gerou, pode descobrir a senha.
a maneira segura é o embaralhamento do código fonte e a segurança a nÃvel de SO. Uso nos meus sistemas SQl Server e os backups dos meu clientes são feitos na Nuvem, Uma copia no OneDrive e uma cópia do Google Drive.
Sem a senha acredito que seja difÃcil ou quase impossÃvel invadir um SQL Server ou um Oracle. o Access não tem segurança, existem programas que dizem a senha do banco.
Eu disponibilizei o programa de criptação aqui:
http://www.vbmania.com.br/index.php?modulo=detalhe&id=9375
Muito interesante seu projeto JCM0867, ele pode ser útil pra iluminar a mente de muita gente que se preoculpa com o que desenvolve inclusive a minha! rsrsrsrs
Aliás todos os participantes estão dando excelentes idéias, melhores e mais robustas. Um dia nós poderemos consolidá-las em uma só.
Eu particularmente gosto muito da forma com que se carrega o caminho do banco de um arquivo externo, pois depois de finalizado o projeto não haveria necessidade de mexer no código fonte para que o programa apontasse para outro(s) servidor(es). Mas é como falei, a brecha é grande!
Mas vc não acha ideal que o usuário do seu sistema informe o usuário DO BANCO DE DADOS para abrir/conectar o sistema/banco de dados ?
mesmo que o [Ô]hacker[Ô] pegue sua string de conexão ele não consegue autenticar sem os dados de usuário, certo ?