Otra de las 10 vulnerabilidades que marca el Open Web Application Security Project (OWASP) tiene que ver con el almacenamiento de la información.

Una de las responsabilidades de todo sitio en Internet, es almacenar de forma segura los datos de sus usuarios. Dependiendo del giro de la empresa responsable del sitio web, éste puede almacenar información como números de tarjetas de crédito, datos personales, historiales médicos, cuentas bancarias, saldos, etcétera.

Por ello, para los administradores es importante garantizar la confidencialidad de esta información, estableciendo, por ejemplo, restricciones para que solo las personas autorizadas puedan leer los datos.

Opciones

Aunque para algunos es una ciencia, la tecnología más utilizada para proteger la información es la criptografía.

Existen varios algoritmos para encriptar la información, pero en general se dividen en dos tipos: simétricos y asimétricos. Los primeros utilizan la misma llave para encriptar y para decriptar. Por otro lado, los algoritmos asimétricos cuentan con una llave para encriptar y otra para decriptar; aquel que posea la llave con que encriptó un documento, no la podrá usar para decriptarlo. Esto se debe a la relación matemática entre las llaves.

La creación de un algoritmo de encripción simétrico se puede comparar con cocinar una pasta. Cualquiera puede preparar pasta, pero no todos pueden cocinar una buena pasta. De la misma forma, el diseño de los principales algoritmos de encripción han estado a cargo de matemáticos y las pruebas han sido realizadas por expertos en el área.

La pregunta que como desarrolladores debemos hacernos, o en su defecto, debemos realizar a nuestros desarrolladores, es: ¿Quién nos asegura que la función de encripción que se está utilizando, en muchos casos diseñada por el mismo desarrollador, no cuenta con vulnerabilidades?

Es que todos lo usan…

Una de las implementaciones más usadas por muchos desarrolladores es un xor entre una llave y la información a proteger.  Esta solución es muy simple de implementar, pero muy insegura. ¿Por que no utilizar algoritmos ya probados como Advanced Encryption Standard (AES), Twofish, RC6, IDEA, Mars, Serpent, etcétera? 

Otro punto a tomar en cuenta es el almacenamiento de las contraseñas de los usuarios, éstas deben encontrarse encriptadas y no en claso o texto plano.

El uso de protocolos tipo reto/respuesta para autenticar a un usuario también es una buena práctica. De esta forma, la contraseña del usuario no viaja por la red. Ahora bien, este tipo de protocolos requieren de un buen algoritmo de generación de secuencias pseudoaleatorias.

La forma más simple de implementar este algoritmo es a través de la función random( ) que proporcionan los lenguajes. Sin embargo, esta función requiere de un valor inicial, generalmente tomado de la hora de la máquina. Es importante que el valor inicial se tome de una fuente aleatoria que no pueda reproducirse posteriormente.

Un ejemplo de mala implementación sucedió con una de las primeras versiones de Secure Socket Layer (SSL) sobre el navegador Netscape, pues permitía conocer la secuencia de bits con la que se encriptaba la información.

No es necesario ser un matemático experto para poder usar los algoritmos. Hoy en día se cuenta con diferentes bibliotecas que agrupan diferentes funciones criptográficas, entre las que se puede mencionar la pagina de Crypto++ (www.eskimo.com/~weidai/cryptlib.html), sitio en el que existe un conjunto gratuito de clases C++.  Es compatible sin cambios en Visual C++ 6.0 SP3 y gcc (y con reservas en otros compiladores Windows, UNIX y Mac).

Sus funciones permiten implementar la mayoría de algoritmos criptográficos, incluidos los cinco candidatos de AES.

Los amantes del lenguaje Java cuentan con la extensión JCE (Java Cryptography Extension en http://java.sun.com/products/jce), así como cryptix ( www.cryptix.org/). Ambas proporcionan librerías gratuitas en Java que permitan implementar los principales algoritmos criptográficos.

En particular, cryptix proporciona un conjunto de funciones que permiten implementar el RFC 2440, que no es otra cosa que OpenPGP. Nótese que no se trata de una aplicación para usuarios, sino de funciones para que los desarrolladores puedan integrar tecnología de encripción o firmas PGP a sus aplicaciones.

No sea negligente

El ego y el desconocimiento de muchos desarrolladores pueden provocar un falso sentido de seguridad al implementar funciones criptográficas que se creen seguras. Sin alguien que pueda verificar el nivel de seguridad de lo implementado, no es posible conocer las vulnerabilidades del sistema basado en estas funciones.

¿Por qué inventar algo nuevo, si ya se cuenta con algoritmos probados por expertos? Es necesario que los desarrolladores conozcan estos algoritmos, usen las implementaciones y no inventen el hilo negro.