Uma forma de esconder o código

Vocês estão usando MySQL connector?
Se tiverem, saiba que ele é GPL e tudo o que tem ele como conector deve ser também.
Mas para proteger de tudo isso acho meia falta de necessidade, o que tem d+ no .class? senha do banco de dados? caminho do banco?

Igor_Barros:

Vocês estão usando MySQL connector?
Se tiverem, saiba que ele é GPL e tudo o que tem ele como conector deve ser também.
Mas para proteger de tudo isso acho meia falta de necessidade, o que tem d+ no .class? senha do banco de dados? caminho do banco?

Hummm … gerador de Senha? Senha que vai ser dada pro usuário? Pronto, não precisa proteger a geração da senha mais

De qualquer modo o WEB-INF é o lugar pra vc colocar … se entrarem no seu servidor nao precisam do gerador de senha, pegam os dados do sistema de uma vez.

smota:

Hummm … gerador de Senha? Senha que vai ser dada pro usuário? Pronto, não precisa proteger a geração da senha mais

De qualquer modo o WEB-INF é o lugar pra vc colocar … se entrarem no seu servidor nao precisam do gerador de senha, pegam os dados do sistema de uma vez.

Grato

Porque não desenvolver então no super, ultra, hiper, mega, master, super Delphi e criar uma ponte entre a aplicação e a web? Assim você terá seu gerador de senhas super protegido e seu site também, mas vale lembrar uma coisa que o CV me disse hoje de manhã.

“Se você esta preocupado com privacidade, porque você está usando windows? Aliás se você estiver muito preocupado, porque está na internet?” by CV

Pq não usa chaves de criptografia?

Não existe fórmula mágica pra isso … o negócio é você ter um bom contrato e bons clientes.

Em algum ponto sua aplicação terá que acessar essa algoritmo, se for web o único jeito será tendo algo no classpath (que está no WEB-INF) e então vc entra no dilema de novo. Se não for web piora pq vc tem que mandar isso pro cliente.

Pelo que entendi a aplicação é desktop certo?

A aplicação terá que entender a formação desse código pra poder validá-lo, certo? Outro furo, o cara pode descompilar o código da aplicação e fazer engenharia reversa … pior, pode usar AOP para alterar o bytecode e burlar a validação … ehehehe :twisted:

É sim, mas é em delphi

smota:

A aplicação terá que entender a formação desse código pra poder validá-lo, certo? Outro furo, o cara pode descompilar o código da aplicação e fazer engenharia reversa … pior, pode usar AOP para alterar o bytecode e burlar a validação … ehehehe :twisted:

Olá
O jeito vai ser fazer um programinha em C com esse algoritmo e gerar uma biblioteca so.
Alguém ai tem um tutorial de como fazer isso em linux? é do mesmo jeito que seria feito com dll?

Cara … qualquer coisa que está conectada na internet não está 100% segura. Entenda e aceite isso.

Sobre ofuscadores, tem esse mais famozinho, sob a LGPL:
http://www.retrologic.com/retroguard-main.html

Aham, vou puxar a brasa para a minha sardinha (trabalho direto com isso, portanto não sou tão leigo assim).
No Java 5 existe um novo provider JCE (PKCS#11 Provider), na verdade a Sun comprou esse provider do pessoal da IAIK.
Esse provider possibilita a você usar hardwares criptográficos, como smartcards e USB tokens.
Por exemplo, você pode ir até o site da Certisign e olhar o preço de um conjunto smartcard (CPF eletrônico) mais um leitor de smartcards, só para você ter uma idéia de quanto isso custa. (Testei esse cartão com o Java 5.0 e sei que funciona. O problema é que o cartão da Certisign é “bloqueado” e não aceita você gerar mais chaves que não sejam o certificado digital; então é necessário obter um cartão de teste com o pessoal da GD Burti, que é o fabricante desses cartões. )
Outros caras que fabricam essas coisas são a Rainbow (eles têm um representante no Brasil, e vendem USB Tokens, que são muito parecidos com aqueles “dongles” que se usam para proteger softwares, ou aqueles USB Drives, mas na verdade sao um conjunto smartcard + leitor em um pacote só.)
O acesso ao smartcard é feito via senha, normalmente; para obter os dados secretos, é necessário digitar a senha e ter o cartão.
Não sei se isso é razoável para o seu problema.
Eu acho que o da GD Burti funciona em Linux; já não sei o da Rainbow, mas provavelmente deve funcionar também.

Lipe, se dependesse de mim eu colocaria de uma vez por todas no WEB-INF.
Mas chefe é chefe… :mrgreen:

Dessa maneira pode não 100% seguro mas ta mais dificil de ser descompilado.

Entao faz autenticacao remota. Ou seja, vcs colocam um servidor de autenticacao e as aplicacoes conectam nele para validar os dados.
Mas sempre havera meios de quebrar. Alguem pode simplesmente crackear a aplicacao para dar um bypass no sistema de validacao. Isso acontece com qualquer software, e se o sucesso da emprsa depender exclusivamente disso, eh melhor mudar de ramo :mrgreen:

Rafael

Eu não me especializei em sacanagem, mas Delphi gera código nativo, assim como C, Pascal e um monte de outras coisas … e desde sempre existem cracks pra tudo quanto é programa e até onde eu sei o crack é feito analisando os bytes do coitado do programa e burlando a parte de seguranca do infeliz, ou seja, continua sendo perfeitamente possível cracker seu super/ultra/mega seguro programa powered by Delphi.

então essa papo de seguro em Java menos seguro que em Delphi é furada, os problemas são os mesmos só burlados com uma arquitetura complexa como os smart cards e tokens (burlados pq isso não resolve, sempre haverá um jeito, só é preciso um pouco de motivação pra se descobrir :roll: )

Que tal gerar os códigos de acesso usando um punhado de dados de 20 lados e mandar o officeboy dizer o código pro cara que comprou o software? Não esqueça da equipe de seguranças e do rastrador no pescoço do coitado do menino. :mrgreen:

HUHAUahuHAuhuaH
E vamos alugar um carro-forte pro officeboy levar o código.
AHauahuhu

Ola!

Estou lendo esse topico e confesso que me perdi no meio de tantas possibilidades. No final das contas fiquei sem saber qual cerne do problema.
Mas se voce deseja uma sistema o mais seguro possivel, poderia pensar em algum tipo de autenticação biometrica. Dá um pouco de trabalho, pois os dados de verificação de biometria devem ser enviando criptografados entre client e server, mas se voce quer garantir que a pessoa é a pessoa mesmo, essa é a melhor opção.
Em relação ao WEB-INF, um servidor Unix, com um bom firewall e um switch L3 ( nem precisa ser router) já são suficientes para garantir a segurança do app server. O que pode ser feito a mais que isso, são regras de rede aplicadas diretamente no kernel do SO.

Lembre-se que as impossibilidades tecnoligicas podem quase sempre ser resolvidas definindo-se procedimentos de utilização do sistema e de sua manutenção.

Espero ter ajudado.

– Ricardo.

rborges:

Ola!

Estou lendo esse topico e confesso que me perdi no meio de tantas possibilidades. No final das contas fiquei sem saber qual cerne do problema.
Mas se voce deseja uma sistema o mais seguro possivel, poderia pensar em algum tipo de autenticação biometrica. Dá um pouco de trabalho, pois os dados de verificação de biometria devem ser enviando criptografados entre client e server, mas se voce quer garantir que a pessoa é a pessoa mesmo, essa é a melhor opção.
Em relação ao WEB-INF, um servidor Unix, com um bom firewall e um switch L3 ( nem precisa ser router) já são suficientes para garantir a segurança do app server. O que pode ser feito a mais que isso, são regras de rede aplicadas diretamente no kernel do SO.

Lembre-se que as impossibilidades tecnoligicas podem quase sempre ser resolvidas definindo-se procedimentos de utilização do sistema e de sua manutenção.

Espero ter ajudado.

– Ricardo.

Amigo, se alguém invadir o seu servidor, seu WEB-INF e roubar o seu .class, pode ter certeza que ele já terá roubado muito mais.

Com certeza, mas o medo do meu chefe é alguém pegar esse algoritmo e sair vendendo códigos de liberação. Vai dar um trabalho convencer ele. :roll:

PS: Daniel vc escreveu uma matéria pra JM sobre thinlet? To lendo agora.

Foi sim! :oops:
Mas já saiu? eu nem tava sabendo. Hehehehehehe.

furutani:

O que eu como programador quero fazer, é arrumar um jeito de proteger esse algoritmo ao máximo.
Um jeito que achei foi escrever um programa em C e criar um .so.

Nem precisa ser .so… um cgi ja da conta do recado. Ai vc usa a minha incrivel http://libcgi.sf.net pra ficar profissa mesmo :mrgreen:

Rafael

É Furutani , tem varias maneiras de se fazer isso … Pelo que vejo o problema maior é convencer o chefe. Faça a melhor analise custo beneficio das opções e exponha a ele. A solução que ele aceitar vc implementa. Essas questões burocraticas sao chatas mesmo.

Outra coisa que eu pensei foi fazer uma interface JNI e chamar um binario mesmo. Ai, vc teria o seu algoritimo protegido. O binario pode ser em C mesmo. Ou entao Faz com Process.exec mesmo. Nem precisa ser tao sofisticado.

[ ]'s

– Ricardo.

IMHO, se o problema está centralizado em se obter acesso ao servidor entao uma boa opção é o que o Rafael citou, criação dessa chave de acesso remotamente…

E se achar q é pouco taca isso numa .so e acessa remotamente…

Sugestão: use certificados digitais em vez de códigos secretos.

Mas pq o uso de certificados digitais faria diferença no caso de uma invasão ao servidor?

Você pode encriptar essas chaves, por exemplo. Então, a posse dos algorítmos por sí só não seriam suficientes.

Diogenes:

Mas pq o uso de certificados digitais faria diferença no caso de uma invasão ao servidor?

Porque não haveria código a ser escondido

Explicar o uso de certificados digitais é uma parada demorada e estou sem tempo pra isso

Só tô dando uma idéia, vocês podem pesquisar, realmente estou sem tempo, gostaria de discutir mais.

Fácil, deixa o class no servidor… se alguém roubar, lance uma atualização do programa invalidando aquele tipo de validação e criando outra. Assim todo mundo que estiver registrado na empresa obterá acesso mediante confirmação do cadastro para implementar uma nova forma de se autenticar e pegar a chave.

Se isso não der certo, bota um httpserver no delphi escondido, que mostra quem é a pessoa que está tentando usar o programa com a chave, se for fria, entra nesse httpserver e invalida o programa dela… hehehehe