Seguridad, criptografia y un poco de astucia

Este post es un tanto técnico, pero explico aspectos de la seguridad de blogmemes, que pueden ser interesantes para los programadores que lean esta bitácora.

El problema de las sesiones persistentes.

Hay una característica que algunos usuarios habían pedido para blogmemes y que me demoré en implementar, puesto que nunca me ha gustado. Esta es la posibilidad de recordar el login, o sesiones persistentes.

Si bien son cómodas para los usuarios, son vulnerables a miles de ataques. Además que deben implementarse con cuidado. Alguien diría, que esas preocupaciones son para sitios y servicios más importantes, pero en realidad me preocupan los usuarios de blogmemes, porque no quiero que nadie les ocupe la clave, y menos obtengan su correo electrónico para recibir spam.

Normalmente esto de las sesiones persistente requiere el uso de una cookie.
Hay muchas implementaciones malas de las sesiones persistentescomo por ejemplo, colocar la clave y el id de usuario en la cookie. He visto incluso casos en que hacen un hash MD5 de la clave y lo almacenan junto con el id del usuario, como si esto brindara más seguridad.

El problema de la cookie, es que estas se pueden copiar, e incluso recolectar. Si estas contienen mucha información, atacar un sitio, o hacer robo de identidad es sencillo.
O basta con robarle la cookie persistente a un usuario, y hacerse pasar por él, (que buena idea, que pasaría si le quitara la cookie a gallir? ñaca ñaca).

En las sesiones permanentes, no debe haber información del usuario, nunca, eso es dar pistas, y expliqué hace tiempo que debemos complicarle la vida al atacante en el control de acceso.

La mejor solución es que la información de sesión permanente se genera en el momento del login, en ella no hay información sensible, sólo un dato generado que me permita internamente encontrar al usuario.

Esta información persistente se renueva en cada nuevo inicio de sesión en linea.

Sin embargo, el problema de la copia del cookie persiste. Por lo tanto, debe impedirse el acceso a información sensible sin que se le vuelvan a pedir credenciales al usuario.
Por eso que en Blogmemes, para modificar el perfil vamos a pedir que el usuario confirme su identidad, a pesar de que tenga una sesión persistente.

Claves MD5

Como saben en blogmemes teníamos las claves en MD5, que como todo el mundo debería saber a estas alturas, no es recomendado para este tipo de labores.
Hemos cambiado, y ahora las claves están almacenadas en forma segura usando AES.

Los que saben de estas cosas, se preguntarán, como logramos cambiarle las clave a todos los usuarios sin tener que pedirle a los usuarios que re ingresen sus claves.

Hemos visto parches cambias las claves a MD5 en la medida que los usuarios hacen login! . No entiendo eso, cuando en mysql uno puede hacer:

update users set clave = md5(clave)

Y problema solucionado. Pero bueno, deben haber razones ocultas que yo no entiendo.

El punto es que en realidad no es necesario conocer la clave en texto plano del usuario para cambiarla de formato, en el caso concreto que estoy contando, lo que hicimos es que a partir de la clave MD5 generamos la nueva.

Si alguna vez quieren hacer el upgrade de sus claves desde MD5 a algo mas seguro como AES, entonces pueden usar esto:

alter table usuarios add clave_fuerte blob;
update usuarios set clave_fuerte = aes_encrypt(clave_debil_en_md5, 'passkey');
alter table usuarios drop clave_debil_en_md5;

Listo. Claro, deben cambiar su codigo para ser compatibles con esto.

PHP

¿Qué pasa si programo en PHP? ¿como soporto AES?, ¿además la nueva clave está en un blob?

Calma, la solución es fácil.

execute_query( "select * from usuarios where usuario = '$id' and aes_decrypt(clave_fuerte, 'passkey') md5('$clave');");

Problemas

El lector astuto se dará cuenta que la seguridad de todo el sistema depende de la famosa 'passkey', que es un string clave que se usa para cifrar y descifrar usando AES.

Esta passkey puede ser la misma para todo el sistema, o puede ser distinta por usuario. Yo personalmente la hice diferente por usuario, con lo que le complico la vida al hacker que intente quitar la clave. La verdad es que uso un esquema mixto, la passkey se compone de una parte que es un atributo del registro del usuario, más una clave general, secreta que se obtiene desde una configuración.

Nuevas oportunidades

Como no tengo las claves originales de los usuarios, de hecho nunca se han almacenado, puedo hacer cosas interesantes, como un modelo challenge - response, en la fase de login, con lo que me evito usar SSL y las claves no pueden ser interceptadas en el camino. Eso es interesante, y se los voy a explicar más adelante.