Cualquier ordenador de pacotilla puede generar un número pseudo-aleatorio. Toma el número de microsegundos que han pasado desde que el reloj interno de tu sistema operativo arrancó, multiplícalo por el valor actualmente en la posición de memoria indicada por ése mismo número, y ya está: Habrás obtenido un número pseudo-aleatorio. Es lo más próximo que estarás de la línea que separa el Universo determinista de la fe en un universo aleatorio. Piénsalo bien: Tu ordenador no juega a los dados.

Dos ordenadores absolutamente iguales generarán el mismo número aleatorio al mismo tiempo, aunque uno esté en Japón y el otro en tu cuarto de baño. Es de escalofrío: sospechosamente parecido a un entrelazamiento cuántico. Piénsalo un poco más, todos los ordenadores del mundo generan números aleatorios de este modo: Cuando juegas a un videojuego, cuando recibes la contraseña para tu tarjeta de crédito, o cuando tu banco online te solicita las coordenadas para confirmar tu operación bancaria. Todo es fruto de un cálculo pseudo-aleatorio que todos damos por válido simplemente porque … sería extremadamente difícil reproducir las condiciones que dieron origen al cálculo.

Ahora piensa un poco más: Tienes un cazo lleno de espaguetis al fuego, el agua ha hervido y has decidido que ya están cocidos: Los viertes en el plato y seis espaguetis caen fuera. ¿Cómo podías saberlo? El número de espagueti, la temperatura exacta de cada molécula de agua en el cazo, la disposición, tamaño y características precisas de cada espagueti, el ángulo exacto en que inclinaste el cazo, la temperatura y la humedad ambiental, el coeficiente de rozamiento del borde del plato … si hubieras tenido todos estos parámetros a tiempo en un sistema de simulación física hubieras sabido cuántos espagueti habrían caído fuera del plato antes de hacerlo. Antes incluso de decidir que querías comer espagueti. Suena a aleatorio, pero no lo es: es pseudo-aleatorio.

Pero ahonda un poco más: ¿Y si tuvieras todos los parámetros que toman partido en la cotización en bolsa de una empresa? Bueno, no serías el primero que lo ha pensado. ¿Y si tuvieras todos los parámetros que afectan al devenir de la humanidad, a cada una de las acciones y reacciones que se producen en absolutamente todos los puntos del planeta, o del Universo? ¿Y si existiera un ordenador capaz de procesarlas en una suerte de software de simulación física monumental? Bueno, tampoco serías el primero que lo habría pensado.

Desde luego, algo es seguro: Todos los parámetros que toman parte en la cadena de acciones por venir son parámetros existentes que pertenecen al presente o al pasado, nunca al futuro. Por lo tanto, todos estos parámetros son observables por definición, dada la tecnología (y el tiempo) suficientes.

Algunos fieles precavidos del Universo determinista opinan que existe un límite teórico en la cantidad máxima de simulación universal posible: Que la complejidad requerida para crear una simulación absoluta del comportamiento del Universo tiende a infinito, consecuencia misma de la infinitud del Universo.

Los fieles optimistas del Universo determinista opinan que en realidad no es tan importante que la complejidad del cálculo y la cantidad de datos necesarios para crear una simulación universal sea infinita: Basta con tomar algunos datos bien elegidos para obtener resultados (léase predicciones) estadísticamente aceptables. El resto puede extrapolarse sin temor a equivocarse demasiado.

A los partidarios del universo aleatorio todo esto les pone los pelos de punta: En el mejor de los casos te dirán que el ser humano no fue diseñado para llegar tan lejos. En el peor de los casos, te dirán que Dios lanza los dados cuando tiene que decidir si un tsunami arrasa la mitad de un país. Los caminos de Dios son inescrutables; de ahí la frase, supongo.

Ahora da un paso atrás para obtener una perspectiva aún más escalofriante: Digamos que dispones de todos los datos que toman parte en tus propios procesos mentales: Todas tus neuronas, sinapsis, procesos químicos y estímulos, dispuestos exactamente en un sistema de simulación capaz de ponerlo todo en marcha del mismo modo que lo haces tu. No parece tan complejo, y tampoco serías el primero en pensarlo: Isaac Asimov, Philip K.Dick, los Wachowskis e incluso Alan Turing o Descartes pensaron mucho en ello.

Sea como sea, sólo hay una pregunta a la que enfrentarse: ¿Es la aleatoriedad del Universo una ilusión de aquello que nos resulta incomprensible, o existe en realidad un mecanismo realmente aleatorio? Y si es así, ¿es éste mecanismo inescrutable?

Te lo juro por el poder de las powerbalance. Se os ocurre alguna más?

En este artículo te explico lo que hay que saber sobre la ley de protección de datos aplicable a proyectos en Internet, y cómo cumplirla al más puro estilo conservador para asegurarte tu rincón en el paraíso de los contribuyentes que jamás burlaron la autoridad. (Si es que quieres terminar ahí, rodeado de gente aburrida cuya idea del paraíso terrenal es una tarde entera de reality-shows)

Cuida de los datos de tus usuarios

Tus usuarios se registran en tu web, rellenan formularios, envían mensajes, publican fotografías, chismorrean, discuten, anuncian, idealizan, promocionan e incluso insultan, critican, desprestigian o simplemente opinan. No pasa nada, Internet es así: igual que la vida misma. Y eso está bien.

Todo este torrente de información termina en tus manos en forma de base de datos, y a merced de tus oscuras intenciones. Sin embargo, si eres de los que prefiere cumplir la Ley, debes saber que según la Ley Orgánica de Protección de Datos (LOPD), estás obligado a cuidar de tu base de datos con el mismo cariño que le profesas al más querido de tus apéndices. En España, el organismo que dispone de potestad para extirpar apéndices, en este caso, es la Agencia Española de Protección de Datos, AEPD para los amigos.

Para la AEPD, tu base de datos se llama “Fichero”, y estás obligado a inscribir tu fichero en sus registros para que conste que recabas esta información. No te preocupes: como otras tantas cosas que probablemente no valores lo suficiente en tu vida, inscribir tu fichero en la AEPD es gratis, y como otras tantas cosas que seguramente sí valoras en tu vida, también puedes hacerlo por Internet.

Inscribir tu fichero en la AEPD no implica que debas enviarles los datos, simplemente estás obligado a inscribirlo para que conste en la AEPD quién realiza la recabación de datos, con qué fin y qué tipo de datos recaba.

El registro donde la AEPD guarda las inscripciones de ficheros como el tuyo, para que no te líes, se llama RGPD. Y al sistema que te permite inscribir tu fichero lo han llamado formulario “NOTA”, sin duda en un alarde de rigor y gusto cinematográfico.

La AEPD distingue dos tipos de ficheros: Los ficheros de titularidad pública y los de titularidad privada. Lo más probable es que necesites inscribir tu fichero con titularidad privada, pues la pública está destinada a los organismos públicos y su insulsa burocracia.

Los tres niveles de seguridad de los datos

Bien, cuando inscribes tu fichero debes elegir uno de los tres niveles de seguridad donde inscribirlo, siendo el primer nivel el que se refiere a la recabación de datos de menor importancia, y el tercero el que deberás notificar si guardas datos escabrosamente privados, veamos:

• Primer nivel: También llamado “I’m too young to die”; el nivel mínimo aplicable, y que debes utilizar cuando los datos que recabas incluyen cualquier dato básico sobre el usuario, como su nombre completo, email, teléfono, dirección, etcétera. Una web con un formulario de contacto, o un sistema de registro muy básico, utilizaría este nivel.
• Segundo nivel: También llamado “Hurt me plenty”; aplicable si además de los datos del primer nivel, también recabas información de tus usuarios sobre sus características físicas, su personalidad o su comportamiento. Una red social normal caería aquí. También requerido para servicios financieros, información sobre solvencia patrimonial o de crédito, información para el tratamiento de obligaciones dinerarias o información para mutuas de accidentes y similares.
• Tercer nivel: También llamado “Nightmare!”; que deberás utilizar si los datos que recabas alcanzan a información del usuario sobre su ideología, afiliación sindical, religión, creencias, origen racial, salud, vida sexual o información relativa a actos de violencia de género. Cuidado, algunas redes sociales requieren este nivel de seguridad!

Cuando rellenes el formulario para la inscripción de tu fichero, bastará con que marques el nivel de seguridad de los datos que contendrá. Pero ojo, estás obligado a cumplir ciertas medidas de seguridad en tu base de datos, que se complican un poco si el tuyo es un segundo nivel, y muchísimo si es el tercero.

Tus obligaciones

Estás obligado a adoptar las medidas técnicas y organizativas que garanticen la seguridad de los datos y que eviten su alteración, pérdida, tratamiento o acceso no autorizado. Aunque la AEPD no especifica qué medidas en concreto, sí estás obligado a asegurar los datos de los riesgos a que están expuestos, ya provengan de la acción humana o de la naturaleza.

Tú y todas las personas que vayan a tener acceso a los datos en el fichero están obligados a guardarlos en secreto, es decir, que no pueden divulgarse ni utilizarse de ningún otro modo que para los fines para los que fue creado el fichero. Además, esta obligación también debe cumplirse incluso cuando los datos se eliminan del fichero (un usuario solicita la baja, por ejemplo), o cuando se da de baja el fichero.

Debes informar a tus usuarios sobre el tratamiento que vas a hacer de sus datos, y sobre cómo pueden solicitar la modificación o la baja. Esto se refiere al típico texto sobre el “acceso, modificación, oposición y cancelación” de datos que deberías tener bien visible en tu web.

Algunas web optan por poner el texto íntegro junto a cada formulario; es la opción más segura. Si te atreves, puedes poner sólo un enlace del tipo “Consulta nuestra política de privacidad” o “Sobre el tratamiento de tus datos”, pero asegúrate de que es bien visible para el usuario, es justamente lo que la LOPD requiere: Si el usuario no encuentra esta información fácilmente, bam!

Un buen texto de ejemplo, escueto y completo para comunicar al usuario y cumplir con esta parte de la LOPD es:

“Los datos que nos proporcionas son incorporados al fichero ”<nombre del fichero>” registrado en el RGPD el día <fecha>, titularidad de <razón social de la empresa o persona física>, cuyo objetivo es el proporcionarte el acceso a las funciones de este web para usuarios registrados, y <detallar aquí otros objetivos de la recabación de datos>. Puedes ejercer tu derecho de acceso, modificación, oposición o cancelación accediendo al menú “tu cuenta” o contactando con nosotros por email a <email> o por teléfono a <teléfono>.”

El documento de seguridad

Estás obligado a crear un documento de seguridad donde se especifiquen todas las medidas que se toman, tanto técnicas como organizativas; los procedimientos en caso de traslado de datos, la seguridad física de los servidores y demás. Según el nivel de seguridad de tu fichero, las medidas de seguridad requeridas pueden ser básicas, comprensibles y asimilables (primer nivel), o inhumanas, excéntricas y retorcidas (tercer nivel).

En cualquier caso, debes saber que la AEPD no inspecciona las medidas de seguridad implementadas cada vez que se inscribe un fichero, pero sí puede hacerlo si lo considera necesario. Debes disponer de un documento de seguridad, y debes cumplir todas las medidas requeridas.

La AEPD ha creado una guía de seguridad que es casi de obligada lectura para cualquier responsable de fichero que se precie. La puedes encontrar en su web, o bájatela de aquí: Guía de seguridad 2010 (versión de diciembre de 2011)

También han creado un documento modelo que puedes utilizar como referencia para crear tu documento de seguridad. Encuentra la última versión en formato Word en su web, o bájate la versión en PDF a diciembre de 2011 aquí: Modelo de documento de seguridad

Cómo inscribir tu fichero

Llegado este punto, ya deberías estar suficientemente acoj..sustado. Y si no lo estás, es que aún no has leído el modelo de documento de seguridad de arriba.

Inscribir tu fichero es fácil y online: Vé a la web de la AEPD y bajo la sección “Responsables de ficheros” encontrarás toda la información detallada que te interesa. Para inscribir tu fichero, sigue estos pasos:

• Averigua el nivel de seguridad de los datos que vas a recabar.
• Crea tu documento de seguridad utilizando el modelo de documento.
• Implementa todas las medidas de seguridad que se detallan en él, si no las tenías aún.
• Añade a tu web el texto para informar a los usuarios.
• Descarga el formulario “NOTA” que encontrarás en la web de la AEPD.
• Rellénalo y envíalo; se envía automáticamente.
• Respira tranquilo, estás siendo legal. Pero no bajes la guardia, ahora tienes obligaciones que cumplir!

¿Y si mi web está hospedada fuera de España?

Es lo más probable. Y la AEPD, en su enorme sabiduría, lo ha considerado: Se considera una “transferencia internacional de datos” si tu servidor no está en la Comunidad Económica Europea, ni en uno de los países considerados por la AEPD como seguros, que a diciembre de 2011 son: Islandia, Liechtenstein, Noruega, Suiza, Argentina, Canadá, Guernsey, Isla de Man y algunos otros países diminutos y remotos.

Si tu servidor está en EEUU, el proveedor de hospedaje debe estar adherido a los “Principios de puerto seguro, Safe Harbor“, que es algo así como una garantía de fidelidad al Rey de España. Infórmate en la web del proveedor sobre ello, o pregúntales; si están adheridos, la inscripción de tu fichero en la AEPD será válida.

Según una resolución reciente, publicar datos en Internet poniéndolos al alcance de todo el mundo no se considera una transferencia internacional de datos. Sin embargo, el hecho de que los datos estén físicamente en un servidor fuera de España, de la CE, de los países seguros (mira arriba), o de los proveedores de hospedaje en EEUU que no estén adheridos al Safe Harbor, sí.

Consideraciones finales sobre la protección de datos

Hay algunas cosas más de cierta importancia que debes saber:

• No importa el alcance tu página web: Tanto si se trata de tu web personal, como de un proyecto multimillonario, siempre que recabes información de tus usuarios, debes registrar tu fichero de datos por igual.
• Tampoco importa que seas un proletario, un estudiante, un emprendedor menor de edad, un jeque árabe o un business angel montado en el dólar: Todo el mundo debe inscribir sus ficheros en la AEPD.
• En la inscripción deben constar todas las personas que van a tener acceso a los datos en el fichero.
• Tener un ordenador desatendido en tu oficina mostrando datos personales de tus usuarios en la pantalla incumple la LOPD! Activa un salvapantallas con contraseña. Ocurre lo mismo con los datos archivados en papel: Deben guardarse bajo llave, y no pueden dejarse a la vista.
• Todas las personas con acceso al fichero deben tener una copia del documento de seguridad, leérselo y seguir todas sus directrices.
• Si vas a enviar SPAM, o si vas a ceder los datos de tus usuarios a otros, que no se te pase por la cabeza “olvidarte de ponerlo”! Especifícalo detalladamente, tanto en tu inscripción del fichero como en el texto para los usuarios, o estás perdido!
• Este artículo se refiere a las leyes que se aplican en España, un país que hay entre México y París, en el que nació Gaudí, vivió Dalí y murió Franco. Otros países tienen otras leyes equivalentes, pero pocos personajes equiparables.
• Es muy recomendable que te pases por la web de la AEPD y te informes a fondo, tienen toda clase de información y respuestas a preguntas comunes. Éste artículo es un resumen; si tienes dudas acude a la web o consúltales a ellos!

Ten en cuenta que es un delito penal no cumplir con todo esto, y las multas pueden ascender hasta cientos de miles de euros, que es una cantidad mayor de lo que cuesta el DVD de “El Gran Lebowski“, un año de cenas japonesas y dos docenas de japonesas … todo junto. Así que merece la pena dedicarle un buen tiempo. La buena noticia es que se trata en realidad de un método para garantizar la seguridad de nuestros datos, y pensándolo bien tú también quieres que tus datos sean tratados con cariño. Así que … espabílate y haz el favor de tratar esos datos como quisieras que trataran los tuyos!

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.

Algo curioso me ocurre cada vez que tengo la oportunidad de iniciar un nuevo proyecto web: En cada proyecto nuevo, termino invariablemente descubriendo algo también nuevo, o profundizando hasta lo más hondo en algo a lo que de pronto descubro no había dedicado el suficiente estudio. Normalmente me encuentro en tales casos profundizando en la usabilidad, el diseño o nuevas técnicas de programación. En este post os hablaré de algo muy concreto pero de vital importancia en la interacción del usuario con una aplicación web: Los botones; cómo organizarlos, cómo diseñarlos, cómo utilizarlos inteligentemente, y algunos de los dilemas en los que curiosamente no habíamos caído hasta que hemos leído algo como este post.

Un botón es un artilugio de cualquier aspecto que ofrece a las personas la herramienta para activar un mecanismo, un procedimiento o una función específica, de modo que las personas que lo utilizan pueden decidir, conociendo la función que ello desencadenará, cuándo pulsarlo.

• Debe tener aspecto de botón
• Debe ser suficientemente autoexplicativo en lo que a su función se refiere
• Debe funcionar tal como se espera que funcione un botón
• Debe responder de inmediato a su uso, ofreciendo un feedback suficientemente explicativo

El otro día descubrí que la luz que se enciende en rojo de mi tostadora es a la vez un botón que permite expulsar las tostadas antes de tiempo. ¡Qué descubrimiento! Tardé meses en darme cuenta.

Veamos algunos ejemplos sobre todo ello. Es curioso observar hasta qué punto no se respeta la humanidad del botón, y nos encontramos cosas como botones disfrazados de vínculos hipertextuales:

haz click aquí para confirmar los cambios realizados, o también puedes volver atrás.

Botones-icono cuyo objeto es un misterio de la usabilidad hasta que el usuario descubre que puede esperar un segundo con el puntero encima para ver el tooltip que explica su función:

Botones que confían ciegamente en la experiencia del usuario:

Por norma general, será una buena práctica tener siempre en cuenta ciertas máximas que se resumen en los siguientes bloques:

¿Hipervínculos o botón?

Un hipervínculo es por definición, de un modo u otro, un enlace a otro contenido que el usuario elige para ampliar la información que está recibiendo, o para continuar su experiencia de navegación hacia otra rama de contenido que la aplicación web le puede ofrecer.

Esto, al menos de un primer vistazo, dista bastante de nuestra definición de botón. Y no es que tengamos que hacer caso de esta definición de hipervínculo tan sólo porque lo diga la wikipedia: hagámoslo también porque es así como lo entendemos como usuarios de la web.

Por lo tanto:

• Hipervínculos: Cuando deseemos ofrecer al usuario una alternativa para obtener más información, para ampliar su flujo de navegación hacia opciones que no son imprescindibles en el proceso en que se halla inmerso, o cuando deseemos ofrecer al usuario la opción de cambiar de tema, o enlazar con una fuente externa. Por ejemplo:
  • Puedes obtener más información haciendo click aquí.
  • Apple presenta su nuevo modelo de ordenador portátil justo a tiempo para la navidad.
• Botones: Cuando la aplicación web ofrezca una función definida por la propia naturaleza del servicio que ésta ofrece, y cuando es el usuario quién debe decidir si ejecutar la acción, y cuándo hacerlo, por ejemplo:
  • aplicar cambios
  • crear un contenido
  • borrar un mensaje
  • identificarme
  • reestablecer mi contraseña

El aspecto del botón o del hipervínculo

Y no es que siempre que introduzcamos un hipervínculo debamos utilizar el recurso común de texto azul y subrayado, ni que siempre que vayamos a utilizar un botón en nuestra aplicación debamos darle el aspecto común de botón tridimensional que se hunde al ser presionado:

• Un hipervínculo común puede transformarse a la percepción del usuario en un botón si lo acompañamos de un icono representativo de su acción, o si lo ubicamos en una lista con “bullets”
• Si necesitamos establecer varios niveles de relevancia entre los botones, podemos incluso crear un estilo común para botones de menor importancia, que se integre de forma menos llamativa en el aspecto del web, y que incluso esté basado en hipervínculos “iconizados”

Así es, entonces, que podemos plantearnos la creación de nuestro kit de botones e hipervínculos de forma clasificada y homogénea, a fin de dotar a la aplicación web de una serie de recursos de usabilidad que en muchas ocasiones serán ya conocidos por el usuario con anterioridad, y en las demás ocasiones tan sólo requerirán de unos breves instantes de aprendizaje, que servirá ya para la utilización de la aplicación web al completo.

A la hora de crear los distintos niveles de relevancia para nuestros botones e hipervínculos, podemos por ejemplo comenzar con la siguiente clasificación, de menor a mayor relevancia:

• Hipervínculos estándar, que se encuentran mezclados en bloques de texto mayor, y que ofrecen la funcionalidad natural del hipervínculo por definición. Por ejemplo, el típico texto subrayado.
• Botones de menor importancia, que preveemos utilizar con asiduidad, y sin embargo no responden a acciones de gran relevancia. Es común diseñarlos como hipervínculos aislados del texto, incluyendo un icono, o un detalle de color o tipografía que los distingue de los hipervínculos estándar. Por ejemplo, el botón “leer más”.
• Botones de acción normales, que ofrecen funciones de importancia moderada, relacionadas con el mismo servicio que ofrece la aplicación web pero que no dan paso a funciones críticas. Por ejemplo: “previsualizar”, “buscar”, “siguiente”, “anterior”, etcétera.
• Botones de acción crítica, que ofrecen funciones importantes relacionadas con el mismo servicio del web, cuyas acciones repercuten directamente en aspectos importantes del servicio. Por ejemplo: “publicar”, “eliminar definitivamente”, “guardar cambios”, “comprar”, etcétera.

El feedback del botón

Un aspecto ampliamente olvidado e injustamente desaprovechado, pues las herramientas de diseño y programación actuales lo permiten fácilmente, es la integración de un sistema de feedback inmediato en la interacción usuario-aplicación.

Se trata de comunicar al usuario el resultado de sus acciones a fin de mantenerle informado sobre su proceso, y evitar la confusión que se produce a menudo cuando existen tiempos de espera intermedios entre la solicitud de una acción y la ejecución de ésta:

• Un botón debe cambiar de aspecto cuando es pulsado
• Un botón no debe poder pulsarse si aún no ha finalizado el proceso de su última pulsación
• Un botón no debe dañar a un ser humano, o por inacción, permitir que un ser humano sea dañado.

Pero más importante aún:

• El botón debe ofrecer feedback visual (o de cualquier otra clase) inmediatamente al ser pulsado, sin retardos.
• Si la ejecución del proceso desencadenado por el botón toma tiempo, debe existir un feedback visual de alguna clase sobre ello.
• Debe comunicarse al usuario mediante feedback de alguna clase la finalización del proceso desencadenado por su pulsación, y su resultado, si se aplica.

¿Qué significa todo ello? Sencillo: El usuario percibirá la fluidez y naturalidad de sus acciones si los botones cambian de aspecto cuando son pulsados (y más aún si ése aspecto sugiere el hundimiento tridimensional típico de los botones reales). Además, el usuario comprenderá que debe esperar después de pulsar un botón cuya acción toma cierto tiempo, si se le ofrece información visual de algún tipo sobre el desarrollo del proceso, incluso aunque sea un simple icono animado del tipo “loading…”

Esta comunicación íntima entre el usuario y la aplicación cambia indudablemente la percepción de la fluidez de la aplicación web: Un web puede volverse intuitivo, usable, rápido y fácil de manejar si simplemente ofrece esta clase de feedbacks en sus acciones, incluso cuando tarde lo mismo en reaccionar y cargar que la misma aplicación sin feedback.

La creación de un interfaz de usuario estandarizado

Sin duda, deberemos pensar también en nuestros botones cuando creemos el look & feel de nuestra aplicación, respetando de un modo u otro estas premisas y, sobretodo, ofreciendo al usuario un conjunto visual “look” y perceptual “feel” inteligente, que incluya, por ejemplo:

• Una tipografía legible integrada con el aspecto visual, con estilos definidos para el texto común, las cabeceras, los listados, etcétera.
• Un set de recursos visuales acordes que ofrezcan la interactividad visual del site de forma unificada en todas sus funciones: Menús, pestañas, desplegables, popups, bloques de información, bloques de publicidad, bloques destacados, etcétera.
• Un conjunto estándar de estilos para botones e hiperenlaces.

Todos estos recursos para la interfaz de usuario deben:

• Ser homogéneos y persistentes en toda la aplicación web.
• Deben adaptarse a los conocimientos estandarizados sobre usabilidad que podemos presuponer en nuestros usuarios y que son de uso común en la web.
• Deben ofrecer un método de aprendizaje para su uso intuitivo, y si es necesario, activamente didáctico.