Federico Almada Blog personal… con lo que se me pase por la cabeza…

Registro de usuarios con recomendación de contraseña

Uno de los problemas que suelo ver de forma reiterada, cuando administro sitios web, es el hecho de que muchas personas no suelen acostumbrar a cambiar la clave por defecto que uno les asigna cuando se les crea su usuario.

He visto que este problema no tiene una buena solución cuando el usuario ya está registrado, ya que las formas implementadas para exigir que se 'cambie' la clave, son un tanto agresivas.
Por un lado, tenemos la petición de renovar la clave cada cierto tiempo. Esto presenta una mejora en seguridad, siempre y cuando el usuario no sea vago/descuidado, ya que supongamos que dicha advertencia le aparece a un usuario de este tipo cuando está apurado... ¿resultado? una clave débil que seguramente será usada para sacar provecho de la cuenta de ese pobre indefenso (esta implementación la he visto en varios sistemas de Home-Banking). También vale mencionar que es bastante molesto, que cada X días, al sistema se le ocurra pedirte que cambies la clave... ¿o no? (fuera de todo aspecto de seguridad... es como si la policía nos exigiera que cambiemos la llave de nuestra casa todos los meses, para evitar robos...).

Por otro lado, tenemos simplemente el aviso de renovar la clave, lo cual suele pasar como "parte" del entorno... ya que nadie lo lee. En este caso, se puede mejorar la idea (lo cual no asegura efectividad), dándole un color (siempre el mismo color, no se me pongan creativos, que luego parece un circo) que resalte al mensaje que estamos intentándole dar al usuario, y que este mensaje solo se muestre en pantalla que no estén involucradas en el medio de una transacción... solo al inicio, o al final de esta. Un ejemplo de como no implementarlo... es poner el aviso de cambio de clave durante un proceso "crítico" -para el usuario-, como efectuar un pago (introduciendo clave, numero de tarjeta, etc). Aunque si podemos implementarlo en las pantallas de menú, o aquellas en donde el usuario esté más tranquilo.

Luego, tenemos los intentos más acertados, los que apuntan a solucionar el problema de raíz (que no están exentos de problemas, aunque minimizan la responsabilidad del administrador del sistema).

Uno de estas formas, es permitir que el usuario elija su contraseña -en el formulario de registro-, lo cual puede convertirse en un serio problema de seguridad para él, si el usuario es vago/descuidado (es el más utilizado).

Otra forma, es sugerir al usuario una contraseña, la cual puede parecer mágica, ya que nosotros como administradores estaremos contentos de que el usuario tendrá una contraseña "fuerte", aunque visto desde el lado del usuario, puede ser inseguro (¿por qué el sistema me sugiere una clave?), y hasta molesto (¿por qué me eligió una clave tan complicada?).

La tercera forma, es muy similar a la primera, ya que consiste en permitir que el usuario elija su contraseña, la primera vez que va a ser uso del servicio. Como habrán notado en este caso, la petición de contraseña no está dada en el registro mismo, sino en el primer encuentro que el usuario tiene con el sistema.

Esta última forma, se puede implementar de dos maneras... una es otorgando al usuario una clave blanca (es decir, vacía), cosa de que cuando haga su primer conexión al sistema, se encuentre con la petición de poner una clave (lo cual puede ser inseguro, si alguien se entera que tal o cual usuario se registró); mientras que la otra es brindarle un enlace para su primera conexión, de modo que en dicho enlace vaya un parámetro de código -aleatorio- (que deberá ser guardado como un campo más en la tabla de usuarios, para verificar luego que sea el mismo)., cosa que no se presente la falla de seguridad anteriormente mencionada en este párrafo (que alguien pruebe y encuentre un usuario nuevo, tomando posesión de la cuenta de este).

El problema es que no siempre podremos brindarle un enlace a un usuario para su primera conexión, dado que el sitio puede estar protegido por .htaccess y la generación de clave "en manos" del usuario es un tanto compleja (dado que el usuario aún no tiene clave, debería ingresar por medio de una página que está fuera de la protección del htaccess, haciendo débil esa parte del sistema); o bien que el sitio se encuentra en una Intranet, por lo que ingresando en el enlace desde fuera de la misma, caemos en la nada. Para estos casos, las otras medidas deberían ser tomadas en cuenta, intentando identificar al usuario medio... ya que si este suele ser vago, entonces deberemos evitar todo intento de complicarle su vida (digamos, que tenga que pensar demasiado).

Para ir cerrando, a modo de prueba, en un sistema basado en Joomla, se modificó el código de cambiar contraseña, para que guarde en un archivo de 'log' cuantos cambio ha habido. En un año, y con más de 190 usuarios, solo se cambió una clave... (¿más triste? fue la mía, de Administrador... para probar si funcionaba el log).

Lamentablemente, si queremos velar por la seguridad de nuestros usuarios, debemos enseñarles los problemas que trae la (in)seguridad, o bien, buscar formas de hacerles vivir en un paraíso donde la seguridad misma reine por si sola