El sistema de registro de usuarios en una aplicación web es uno de los asuntos que hay que cuidar con más detalle, no sólo en lo que a su diseño y usabilidad se refiere, sinó también en las medidas de seguridad que debería implicar.

El paso de los años nos ha enseñado mucho sobre cuáles son las prácticas que funcionan mejor en los sistemas de registro, y algunas malas experiencias nos han enseñado mucho sobre cómo garantizar la autenticidad del usuario, evitar la suplantación, la duplicidad, y mucho más.

En este post hablo sobre mis conclusiones al respecto, y perfilo un modelo completo de registro de usuarios que, a mi parecer, se acerca lo más posible a un sistema de esta clase seguro, lógico, y a prueba de muchos de los problemas que tanto hemos sufrido como desarrolladores, y como usuarios.

El email como identificador de usuario

En todo este tiempo nos hemos dado cuenta, por ejemplo, de que casi siempre es mejor identificar al usuario por su email en lugar de utilizar un nick o seudónimo. ¿Porqué?

• Usar el email del usuario como su identificador, junto con su contraseña, nos permite obtener directamente un método de contacto con él.
• Un email como identificador nos permite enviar un mensaje al usuario para confirmar su registro, y obligará al usuario a utilizar un email válido, garantizando así nuestra vía de comunicación.
• Las direcciones de email son únicas, no debería haber problemas de duplicidad: Cuando un usuario intenta registrarse con un email ya existente, tan sólo puede ser por dos motivos:
  • El usuario se registró con anterioridad y no lo recuerda, o olvidó su contraseña y decide registrarse de nuevo en lugar de utilizar un sistema de recuperación de contraseña.
  • Alguien está intentando suplantar al usuario.
• Un email es mucho más fácil de recordar para el usuario que un nick o un seudónimo. En un principio, podemos tener muchos nicks, pero tan sólo una dirección de email.
• Con un email como identificador, podemos dar al usuario la posibilidad de especificar también un seudónimo adicional. En tal caso, no importará si el seudónimo ya fué elegido por otro usuario; podrán existir seudónimos repetidos, si queremos.
• Un email como identificador permite fácilmente implementar un sistema de recuperación de contraseña del tipo “introduce tu email y te enviaremos un mensaje con un enlace para que puedas cambiar tu contraseña”

La comprobación del email

Para asegurarnos de que la dirección que introdujo el usuario es correcta, podemos mandarle un email con un enlace que le permitirá confirmar que efectivamente, él es la persona que recibió dicho email. Con ello habremos confirmado nuestra via de comunicación.

En algunos casos, si no nos interesa desviar la atención del usuario durante el registro, y queremos facilitarle la consecución de una acción justo después de registrarse como nuevo usuario, podemos facilitar el login de éste inmediatemente después de haber introducido sus datos para el registro, y realizar la comprobación del email de forma diferida. Se trata, por ejemplo, de un aviso en la pantalla como:

“aún no has verificado tu email, consulta tu correo y haz click en el enlace que encontrarás, o pulsa aquí para que te enviemos de nuevo el email de confirmación”

En cualquier caso, tendremos que tener en cuenta varios aspectos al solicitar el email del usuario durante su registro:

• El enlace de confirmación de registro que le mandemos al usuario en un email deberá contener algún mecanismo de seguridad para evitar que cualquiera, conociendo la sintaxis de dicho enlace, pudiera confirmar su registro sin necesidad de recibir el email.
• Es común que un usuario se equivoque al introducir su dirección de email durante el registro, con lo que perderíamos su registro: En tal caso, no vendría mal solicitar al usuario introducir su email por duplicado, como hacemos con las contraseñas.
• Es fácil verificar ciertos parámetros en la sintaxis del email que introduce el usuario para asegurarnos de que introduce un email verdadero: Basta con comprobar la sintaxis del dominio al que pertenece, e incluso averiguar si existe un registro MX en las DNS para ése dominio.
• Existen varios servicios en internet que permiten obtener una dirección de email perecedera como MintEmail.com, diseñados especialmente para registrarse en sitios web que requieren confirmación de email de forma anónima. Podemos crearnos una lista de estos sitios y comprobarla durante el registro.

El almacenamiento de la contraseña

Para garantizar un poco más la seguridad de los datos del usuario, es común almacenar su contraseña encriptada en nuestra base de datos mediante algún algoritmo “one-way” como MD5 (ya no muy recomendable) o SHA.

De este modo, evitamos guardar la contraseña del usuario en nuestra base de datos, lo único que podemos hacer es comprobar si la contraseña que nos especifica un usuario al identificarse es correcta o no.

La contrapartida de este método (que aceptamos sin más), es que jamás podremos recordarle la contraseña al usuario. Lo que sí podremos hacer es proporcionarle una nueva, generada aleatoriamente.

Comprobación de seguridad de la contraseña

La debilidad de muchos sistemas, y el robo mismo de las contraseñas, casi nos obliga a utilizar una contraseña distinta para cada sistema en el que nos registramos. Muchos usuarios terminan utilizando una única contraseña para todos sus registros, otros más avezados disponen de contraseñas distintas según el nivel de seguridad que requieren para cada entorno en el que se registran.

Pese a todo, la concienciación del usuario respecto a la seguridad de su contraseña sigue siendo muy vaga, y actualmente existen aún varias pautas que originan el robo de las contraseñas:

1. Contraseñas pobres: que son fácilmente descubiertas mediante sistemas automáticos de bombardeo, ataques de diccionario o similares.
2. Contraseñas irresponsables: Cuando la pereza nos puede, y utilizamos contraseñas demasiado sencillas como “12345″, que corresponden con nuestro mismo nombre de usuario en el sistema, con nuestro día de nacimiento, o similares.
3. Contraseñas robadas: Aquéllas que, en un momento dado, apuntamos en algún lugar visible o entregamos a alguien.
4. Sesiones de usuario sin cerrar en ordenadores públicos: Cuando dejamos una sesión abierta después de trabajar en un ordenador al que otras personas tienen acceso, es muy sencillo suplantar al usuario con la sesión que él mismo abrió, y cambiar la contraseña.

Existen workarounds para cada una de estas causas, y seguramente muchas más. En definitiva, lo que sí podemos hacer a priori es implementar en nuestro sistema de registro un método que verifique precisamente la fiabilidad de las contraseñas. Existen sistemas ya desarrollados para ello que podemos implementar, como Password Strength Meter, de Phiras, entre muchos otros que se encuentran fácilmente.

El proceso de recuperación de contraseña

Con el proceso de recuperación de contraseña comienzan los escenarios que pondrán realmente a prueba la fiabilidad de nuestro sistema de usuarios. Aunque la recuperación de contraseña es el proceso más sencillo y menos expuesto a problemas de seguridad, hay varias alternativas. Para comenzar, diremos que el proceso de recuperación de contraseña se inicia:

• Cuando el usuario no recuerda su contraseña.
• Cuando el usuario recuerda su contraseña, pero quiere cambiarla.
• Cuando alguien que no es el usuario intenta averiguar la contraseña de éste.
• Cuando alguien que no es el usuario desea perjudicar al usuario, cambiándole la contraseña.

Y para ello tenemos varias soluciones:

• Solicitamos el email del usuario, comprobamos que corresponde a un usuario en nuestra base de datos, generamos y le asignamos una nueva contraseña, y le remitimos un email con ésta.
• Solicitamos el email del usuario, comprobamos que corresponde a un usuario en nuestra base de datos, y le remitimos un email con un enlace que le dirigirá a un entorno donde podrá elegir una nueva contraseña. Este enlace, obviamente, deberá incluir un sistema de verificación para evitar que cualquiera pueda utilizarlo conociendo simplemente su sintaxis.

Ambos métodos son razonablemente seguros, aunque puede darse que el usuario haya sido víctima de un ataque deliberado, y la persona que ha iniciado el proceso de cambio o recuperación de contraseña sea alguien malintencionado que tenga también acceso a su cuenta de email. Ocurre más a menudo de lo que uno cree, y en muchas ocasiones termina en una catástrofe común para los administradores de los sitios web que permiten el registro de usuarios, la llamaremos “La catástrofe del usuario razonablemente sospechoso”, y lo veremos más adelante.

El proceso de recuperación de nombre de usuario o email

No podemos contactar con el usuario porque él mismo no conoce cuál es su identificador en nuestro sistema, suponemos que el usuario habrá intentado identificarse utilizando todos los emails, nombres de usuario y contraseñas que pueda recordar, y sus combinaciones. Suponemos también que no ha tenido éxito y por ello nos contacta. Demasiado suponer. En tal caso, no nos queda más remedio que hechar mano de una de las más sabias máximas de la informática:

Podemos diseñar un sistema de seguridad a prueba de todo, menos del descuido humano.

La catástrofe del usuario razonablemente sospechoso

Un sistema de registro de usuarios que no haya sido cuidadosamente confeccionado desembocará inevitablemente en numerosas catástrofes de esta clase. Llamamos “catástrofe del usuario razonablemente sospechoso” a aquélla que se da cuando, después de un supuesto ataque contra el registro de un usuario, perdemos toda fiabilidad sobre su autenticidad. En tales casos, ocurre que perdemos el vínculo con el usuario auténtico (o al menos, con el usuario que realizó originalmente el registro), y no podemos garantizar que la persona que solicita la baja, el cambio de email o de contraseña, o que exige la cancelación de un usuario que supuestamente le está suplantando, sea realmente él.

Esta catástrofe, que seguramente ha originado pérdidas millonarias en bases de datos de usuarios, y sin duda estará ya siendo investigada por las más altas esferas de la regulación de la Ley, puede llevarnos simplemente a dos conclusiones:

• Perdemos un usuario, que no sin razón se enfada al no poder recuperar su cuenta.
• Perdemos un usuario, que ha sido suplantado por un desconocido con oscuras intenciones.

¿Y hasta qué punto y con qué herramientas podemos lidiar con la C.U.R.S.? Puesto que las armas de fuego son consideradas la mayoría de las veces muy poco éticas, ruidosas e ilegales, tan sólo nos quedan unos pocos recursos técnicos que pueden ayudarnos a evitar la temida C.U.R.S., como un sistema secundario de autentificación, del que hablo más adelante.

El sistema secundario de autentificación

El único método práctico y legal en nuestra lucha contra la C.U.R.S: Creemos un sistema que nos permita averiguar si estamos hablando con el usuario auténtico o con un suplantador. Una contraseña, por ejemplo.

- ¿Otra contraseña?

Sí, quizás algo equivalente por ejemplo al conocido código PUK en los teléfonos móviles, una clave corta secundaria que el usuario seleccione durante el registro.

Bueno, también podemos hacerle una pregunta de la que sólo él tenga la respuesta, así nos aseguraremos, por encima de cualquier email y contraseña, que es él quien nos habla.

Sea el que sea el sistema de clave secundaria de autentificación, deberá inevitablemente cumplir los siguientes requisitos:

• Sólo el usuario debe conocer la clave
• Nosotros debemos conocerla también, para poder verificarla
• Debe ser muy difícil de averiguar por un tercero
• No debe ser un dato que esté disponible para visualizarlo o modificarlo cuando el usuario se identifica en nuestro sistema, pues el mismo suplantador con acceso a la cuenta del usuario suplantado podría verlo o modificarlo, con lo que se acabó nuestra gran idea de autentificación.
• Debería ser una clave que el usuario pudiera recuperar fácilmente si tiene mala memoria. Puesto que se trata de una clave secundaria que no se usa prácticamente nunca, es muy fácil que el usuario la olvide.

¿Cuándo utilizaremos este sistema secundario de autentificación? En los casos en los que exista un atisbo de duda sobre si el usuario está siendo suplantado o no. En muchos de ellos, este sistema secundario será lo único de lo que podremos fiarnos, y es por ello que debe ser fuerte; por ejemplo:

• Cuando el usuario ha perdido el acceso a su correo electrónico y olvidó su contraseña, por lo tanto, no puede realizar el proceso de recuperación de contraseña.
• Cuando el usuario detecta que le han suplantado y robado la contraseña, puede autentificarse mediante este sistema secundario y cambiar el email o la contraseña de su cuenta, o darla de baja sin más para evitar la suplantación. El suplantador no debería conocer la clave del sistema secundario, pues no puede verse si modificarse incluso una vez indentificado en el sistema.

A parte de la opción de un código secundario estilo PUK, existen varias alternativas que funcionan muy bien, pero sólo cuando se diseñan correctamente, por ejemplo:

El sistema secundario de autentificación mediante una pregunta-respuesta

Damos al usuario la opción de elegir una entre varias preguntas, y después le obligamos a escribir su respuesta. Se trata de un sistema de fácil uso para el usuario, y que apela a la mala memoria patológica de que sufrimos los humanos, pues presupone que nos resultará fácil recordar el nombre de nuestra primera mascota, o el primer apellido de nuestra abuela. Sin embargo, si dichas preguntas no se eligen con cuidado, en lugar de un sistema de seguridad puede convertirse fácilmente en un agujero oscuro mate de seguridad de proporciones cósmicas (seguramente, 1×4×9)

¿Qué preguntas no debemos utilizar nunca para un sistema así? Aquéllas cuya respuesta sea fácilmente averiguable, o muy débil frente a un ataque de bombardeo o de diccionario, por ejemplo:

• “¿Cuál fué el nombre de tu primera mascota?” es una pregunta con apenas unos miles de respuestas posibles: un sistema de bombing averiguaría la respuesta en pocos segundos.
• “¿En qué año naciste?”, a parte de resultar un dato muy fácil de averiguar, incluso simplemente buscando por internet datos sobre el usuario, caería estrepitosamente en unos pocos milisegundos ante un ataque de bombardeo, pues pueden recorrerse fácilmente los números del 1900 al 2009, y la respuesta estará sin duda entre uno de ellos.
• “¿Qué pueblo te trae recuerdos de la infancia?”, es un ejemplo de carne de cañón para un ataque de diccionario: no hay suficientes pueblos en España o en el mundo como para resistir un bombardeo de nombres.
• “¿De qué color es tu coche?”, “¿Cuántos años tenía tu madre cuando se casó con tu padre?” y otras preguntas similares desembocan siempre en catástrofes de seguridad que cualquier bombing sencillo puede provocar.

Entonces, ¿qué pregunta podemos hacerle al usuario, cuya respuesta sólo conozca él, que no sea susceptible de un ataque de diccionario o de bombing, y que le sea fácil recordar?

Muy pocas en realidad, y se trata de un ejercicio complicado averiguarlas. Por ejemplo, las siguientes:

• ¿Cuál es el número de serie de tu ordenador portátil o de tu reproductor MP3?
• ¿Cuál es el código IMEI de tu teléfono?
• ¿Cuál es el número de tu tarjeta VIPS Club, o de tu tarjeta DobleCero?

Todas ellas son preguntas cuyas respuestas difícilmente podrían ser averiguadas por un bombardeo o un ataque de diccionario, y suponemos que serán datos que no es necesario que recuerde el usuario, pues puede encontrarlos entre sus pertenencias personales. Pese a lo tedioso de pedir estos datos al usuario (podemos mostrarle un ejemplo de cómo averiguar el número de serie de su reproductor MP3, o el código que debe teclear en su teléfono para obtener el código IMEI), éstas serían preguntas cuyas respuestas nos garantizarían con mucha seguridad la autenticidad de la petición del usuario de cambiar su contraseña o su email, o de dar de baja su cuenta asegurándonos que no es un suplantador quien lo solicita.

Sistemas de autentificación secundaria avanzados

Los implementan las aplicaciones web que realmente no se la pueden jugar en lo que se refiere a la privacidad de los datos de sus usarios, o que son muy susceptibles de recibir ataques de suplantación de personalidad debido al gran número de usuarios que sustentan. Las aplicaciones de banca online, o los “grandes” de internet, como Yahoo!, MSN y Google, por ejemplo. Son sistemas adicionales “para nota”. Por ejemplo:

• Tarjetas físicas de códigos organizados por coordenadas, que se envían por snail mail certificado, y cuyas claves son únicas para el usuario, y quedan almacenadas en el servidor seguro de la aplicación web para poder ser comprobadas. De tal modo, sólo el usuario puede autentificar las operaciones delicadas que realice. Felizmente, alguien que haya tenido acceso a la cartera del usuario y haya fotocopiado su tarjeta de claves, también podrá acceder en su nombre a su banca online. Seguramente para ayudarle en sus tediosos trámites y transferencias bancarias, blandiendo el lema “el dinero no da la felicidad, así que voy a hacerte inmensamente feliz”
• Generadores electrónicos de claves únicas embutidos en un llavero personalizado para el usuario, que muestran en una pantalla una clave específica cada cierto número de segundos, que se le solicita al usuario cuando debe utilizar este sistema secundario de autentificación. Verisign, por ejemplo, ha creado un servicio así con su iniciativa Verisign Identity Protection.
• El DNI electrónico, que para nuestra suerte lleva ya un tiempo disponible e implementándose en España, y nos permite identificar unánimemente a nuestros usuarios mediante su certificado oficial expedido por el mismísimo y excelentísimo Gobierno, del cual deberíamos podernos fiar. Parece una alternativa excelente, aunque por el momento algo exigente para con el usuario y sus conocimientos técnicos, pues no es cosa fácil instalar un certificado así en tu navegador.
• Un chip RFID nanotecnológico implantado bajo la piel, algo así como lo que utilizaba el control de acceso de teletransportación en Star Trek, para evitar que cualquier hacker pudiera entrar en la Enterprise simplemente sintonizando la frecuencia exacta en su portátil. El RFID es un chip de fabricación muy barata y fácilmente implementable en casi todo lo imaginable, que emite un código único de identificación (o cualquier otro dato que queramos grabar en él). Un receptor situado a cierta distancia puede leer los datos que emite el chip RFID, y después de contrastarlo con una base de datos (suficientemente segura, espero), identificarlo de forma única y segura. En Minority Report hicieron algo parecido con la lectura biométrica remota del iris. Parece que en un futuro el RFID podría darnos también una alternativa buena de autentificación segura. Espero que no comiencen a surgir los delicuentes de escalpelo, arrancando los RFIDs de bajo la piel.

Resumen

Como conclusión de este análisis, un resumen de los puntos clave que debe cumplir lo que probablemente sería la implementación de registro de usuarios más razonablemente segura:

• Una primera fase de registro con un email y una contraseña.
• Una comprobación activa de la validez del email.
• Un sistema seguro para el cambio de contraseña o de email, que sea capaz de funcionar incluso cuando el usuario perdió el acceso a su buzón de email y olvidó su contraseña al mismo tiempo, para combatir el temido C.U.R.S.
• Una aplicación inteligente de los sistemas de seguridad (Nada de preguntas y respuestas del tipo “el nombre de tu mascota”), y un control responsable y seguro de los datos en el servidor de la aplicación (un buen administrador de sistemas sabrá bien a qué se refiere este punto)
• Un interfaz y unos procedimientos usables que no sean demasiado exigentes con la memoria del usuario.
• Una política correcta de salvaguarda legal de los datos. En España, según la Ley de Protección de Datos LOPD.