Em Por que minha criptografia não está… criptografando? aprendemos que sua criptografia é tão boa quanto sua compreensão do código de criptografia. E que a melhor criptografia de todas é a não criptografia, porque o senhor mantinha tudo no servidor, longe dos olhos curiosos do cliente.
Em A parede do banheiro do código aprendemos o perigo potencial de copiar e colar código da Internet e a importância contínua da revisão regular por pares de cada linha de código que entra em sua base de código, seja qual for a fonte.
Eu não esperava que essa série se tornasse uma trilogia, mas aparentemente se tornou, porque Thomas Ptacek, da Matsano Security escreveu um longo post no blog sobre o assunto. Uma entrada de blog disfarçada de um roteiro de faculdade excessivamente dramático, mas ainda assim. Esses caras, ao contrário de nós, são verdadeiros especialistas em segurança, portanto, vale a pena ler.
Mas o senhor não precisa ler esse roteiro, porque vou revelar a reviravolta no ato final aqui mesmo.
- A raiz do problema não era não entendendo a criptografia.
- O problema principal não era copiando e colando código da Internet.
- A raiz do problema não era não conseguiu revisar o código por pares.
O Sr. Ptacek está absolutamente certo. A raiz do problema foi que o estávamos trabalhando na camada errada de abstração.
Em vez de construir código a partir dos primitivos de criptografia de baixo nível fornecidos no .NET, deveríamos ter usado uma biblioteca para lidar com nossas necessidades de criptografia. Lembro-me de um piada comum do Stack Overflow:
P: Como faço para escrever isso em JavaScript?
R: O senhor não usa. O senhor usa JQuery.
O senhor pode economizar uma quantidade enorme de tempo e esforço usando a estrutura independente de navegador que a JQuery gastou incontáveis horas de trabalho testando, depurando e comprovando em campo. Embora não haja nada errado com a escrita em JavaScript, por que não acelerar seu tempo de desenvolvimento escrevendo na biblioteca? Como eu sempre disse, não reinvente a roda, a menos que planeje aprender mais sobre rodas.
As abstrações são importantes. O senhor poderia considerar a maior parte da história da programação de computadores como uma lenta e dolorosa escalada na árvore evolutiva da abstração: da linguagem assembly, ao C, ao Java, ao JavaScript, até o JQuery, onde o ar começa a ficar bem rarefeito. Já colocamos em camadas um sistema operacional, um navegador da Web, e linguagem de script interpretada, uma em cima da outra, para chegar a esse ponto. É uma prova do poder da abstração que tudo isso funciona.
Voltando aos aspectos específicos: como o senhor pode impedir que os programadores trabalhem na camada errada de abstração? Uma solução seria proibir totalmente as primitivas de criptografia do .NET. Isso é semelhante à proposta de Steve Gibson de cruzada santa contra a programação de soquetes brutos no Windows XP. Suponho que essa seja uma maneira de fazer isso. Mas colocar obstáculos na frente dos programadores é equivalente a um desafio; por que não oferecer a eles alternativas mais atraentes?
Ocultar os primitivos de criptografia de baixo nível parece ser uma solução temporária. Dito isso, eu fortemente recomendam marcar alguns dos métodos de criptografia mais antigos como obsoletosAssim, os programadores que tropeçam em algum caminho de código antigo e empoeirado pelo menos têm algum sinal de aviso de que estão usando um algoritmo com muitas vulnerabilidades conhecidas. Estou imaginando um Clippy que aparece com algo como:
“Ei! Parece que o senhor está usando um método de criptografia que é amplamente considerado inseguro pelos especialistas em segurança! O senhor gostaria de ver alternativas?”
Uma dessas alternativas seria uma biblioteca completa, talvez algo como Bouncy Castleou Keyczarou cryptlib. O que poderia ser mais fácil do que um EncryptStringForBrowser() que tem segurança e resistência a violações incorporadas, que faz parte de um conjunto de código comprovado e testado por especialistas no domínio, no qual milhares, se não milhões, de desenvolvedores já confiam?
O uso de bibliotecas de criptografia não significa que os erros cruciais de criptografia desaparecerão magicamente da noite para o dia. Mas essas bibliotecas, por forçarem os desenvolvedores a trabalhar em um nível mais alto de abstração, fazem com que mais difícil fazer mau uso da criptografia. E, talvez o mais importante, os aprimoramentos de usabilidade da biblioteca podem ser mais bem tratados pelos especialistas que criaram a biblioteca, em vez dos generalistas que trabalham na própria estrutura .NET.
Portanto, da próxima vez que o senhor se propuser a escrever código – não apenas código de criptografia, qualquer pergunte a si mesmo: Estou trabalhando no nível certo de abstração?