Criptografia no ColdFusion

Em um recente thread sobre criptografia na lista CF-Brasil, fiz algumas considerações, e atendendo a pedidos (quanta modéstia!) posto aqui no blog.

A primeira coisa é ententender sobre qual tipo de criptografia estamos falando. Há a criptografia de dados que trafegam pela aplicação, em que utilizamos as funções Encrypt(), Decrypt() e Hash(). O ColdFusion 7 oferece uma variedade de algorítimos padrão de mercado e já consagrados como fortes, como TripleDES. A outra criptografia que pode ser abordada é do código da aplicação.

As funções Encrypt() e Decrypt(), são, óbviamente, utilizadas em pares. Você usa uma para codificar, e outra para descodificar, em ambos os casos sabendo qual a chave que foi utilizada. Para gerar chaves de criptografia, você pode utilizar a função GenerateSecretKey(). Portanto, o código é “desencriptável”, afinal, é possível fazer o caminho de volta. É o chamado two way encryption, em que pode-se encriptar, mas também é possível desencriptar. É bastante seguro se você tiver certeza que só você sabe a chave, e ela atender os requisitos mínimos de segurança (não for “aaa”, “123”, etc..).

Mais detalhes sobre os algorítimos disponíveis para estas funções nesse technote da Macromedia e na própria documentação do CF7.

A função Hash() é utilizada para criptografia de caminho único, isto é, só é possível encriptar, não desencriptar. Embora pareca estranho de início é bastante comum e seu uso é quando você não precisa saber o que está escrito, mas apenas comparar, como no caso de comparar uma senha digitada com uma base de dados para verificar se esta é válida. É como o login em sistemas *nix funciona: a senha desses sistemas não é “desencriptável”, mas apenas “comparável”. Ele guarda as senhas em formato criptografado, e quando o usuário digita a senha, ele criptografa e compara a string criptografada para verificar se a senha é válida.

É como alguns sistemas fazem: não é possível recuperar a sua senha, afinal, nem o próprio sistema sabe qual é a sua senha. Quando você perde sua senha, ele gera uma nova senha para você, e guarda o encriptado da nova senha no banco de dados.

Para “quebrar” esse tipo de senha é utilizada uma técnica chamada de “brute force”, em que um pequeno programa encripta uma infinidade de senhas (exemplo: todas as combinações possíveis utilizando de 1 a 9 e de a à z que contenham de 4 a 10 caracteres). É claro que essa técnica demora muito tempo, e se torna praticamente inviável (em tempo) se sua senha atender os requisitos mínimos para uma senha de qualidade (não usar caracteres repetidos, ter um mínimo de “n” caracteres, etc..), o que torna esta função (Hash()) bastante segura se utilizada corretamente.

E novamente repito: ter uma senha que atenda os requisitos mínimos de segurança para uma boa senha. É muito do bom senso, mas há inúmeras referências sobre o assunto na Internet, e inclusive uma interessante aqui no CFGigolô.

Mais detalhes sobre estas funções na referência do ColdFusion 7.

Um outro entendimento sobre a criptografia é a referente ao código CFML, que utiliza um utilitário chamado cfencode. Há mais informações sobre no site da Macromedia e na documentação do produto. Embora ele realmente codifique seu código CFML, diferentemente de uma criptografia que utiliza uma chave que só você deve saber, a chave é, “única”, isto é, é sempre a mesma chave. Afinal, o ColdFusion Server precisa saber qual é a chave para poder “decodificar” o template CFML e executá-lo.

Não sei fiz me claro: quando utilizamos a função Encrypt() fornecemos uma chave que só nós sabemos, e que a pessoa que tentar quebrar deve descobrir antes de desencriptar. No caso da codificação do template CFML, uma vez que o ColdFusion Server precisa “decodificar” para poder executa-lo, ele sempre “chave” de codificação, afinal ela é sempre a mesma. Não é uma codificação perfeita (nem programas em C++ o são), mas dificulta bastante crackers menos experientes. Bem, não preciso dizer que isso é suscetível em qualquer ambiente que utilize uma técnica parecida, não é? Só para fazer uma comparação, em aplicações Java, arquivos .class são gerados e facilmente convertidos novamente para o código Java original.

Agora, se o escopo é focar na segurança, há muito mais a ser dito. A uma série de outras tags e funções que auxiliam na segurança, tanto da aplicação (quando o programador está desenvolvendo) quando à administração do sistema, que também é uma peça fundamental. Há boas referências aqui no blog, onde além de outros posts sobre o assunto, há o artigo sobre sandbox e segurança em ambientes compartilhados (provedores) do Alex Hübner.

O ColdFusion oferece uma séries de técnicas e funções que auxiliam na segurança, mas por si só não basta. Como em qualquer ambiente, depende mais da equipe que programou a aplicação, ou do admin que gerencia os servidores do que do próprio servidor de aplicação. A questão aqui não é a tecnologia, que acredito ser muito boa e oferecer os recursos necessários, mas as pessoas que a utilizam, bem ou mal.