¿Por qué el "login" o identificador de usuario es usado como un campo clave?

Hace unos tres años tuve una pequeña controversia con un ingeniero de una empresa a la que prestabamos nuestros servicios, simplemente porque él consideró un exabrupto el hecho de que yo le propusiera que usara un campo clave diferente al identificador de usuario convencionalmente conocido como "login" en la tabla de los usuarios de su aplicación web. No fué ese el único caso en el que sentí que las personas a quienes proporcioné dicho consejo lo tomaron como una locura por no decir algo peor.

Pero póngamonos a reflexionar un instante: En la actualidad todos los sistemas de manejo de bases de datos relacionales (MySQL, PostgreSQL, MSSQL, PL-SQL y otros) manejan tipos de campos de identificación de registros que se generan automáticamente de forma más que eficiente y que en muchos casos suelen ser utilizados como los connocidos IDs (Id_user por ejemplo). Estos pueden contener hashes únicos, ser campos autonuméricos secuenciales o simplemente identificadores aleatorios a gusto del programador.

El campo comunmente conocido como "login" si bien tiene que ser demostradamente único para un determinado usuario no necesita ser utilizado para identificar un determinado registro de usuario en un grupo de tablas relacionadas. Existen muchos otros identificadores más sólidos y fiables como por ejemplo el número del documento de identidad del usuario o simplemente un campo clave autogenerado.

Aclaremos, no hablo de eliminar el identificador de usuario de los procesos de validación de ingreso, lo que estoy proponiendo es que este campo no sea utilizado como campo clave del registro ya que esto último es una limitación seria de seguridad en la mayoría de los casos, ya que al ser un campo clave relacionado con otras tablas y procesos, no podremos cambiar su contenido.

Todos aquellos que hemos hecho alguna vez un sistema de control de acceso, sabemos que ciertas rutinas como aquellas de recuperación y cambio de clave de acceso son ciertamente parte obligada de dichos sistemas, debido a que bajo un concepto de seguridad obsoleto, el campo correspondiente a la clave de acceso soporta todo el peso de la seguridad del proceso de validación de ingreso. Esto puede variar, si permitimos que también pueda ser cambiado el campo correspondiente al identificador del usuario.

Imaginemos el ejemplo típico en que una persona en una empresa detecta el "login" del administrador o gerente de la misma en una interfaz de acceso de un programa o aplicación de banca en línea. Para poder penetrar en la aplicación solo necesita conocer el password. Imaginemos también que este segundo dato es obtenido mediante cualquier proceso de hacking o ingeniería social de los tantos existentes y que el gerente de la empresa se percata o sospecha que alguien ha utilizado sus datos de acceso. El paso siguiente será cambiar la clave para tratar de que el atacante no pueda ingresar nuevamente. Sin embargo si no conoce el proceso por el cuál su clave ha sido vulnerada (vector de ataque) lo más probable es que en poco tiempo el atacante pueda nuevamente conocer dicha clave y entrar nuevamente en la aplicación.

Sin embargo otra cosa sería que el atacante tenga nuevamente que descubrir dos campos, ya que en nuestra aplicación hemos permitido (verificando que no puedan existir duplicados) que el usuario pueda cambiar no solo la clave de acceso sino también el identificador de usuario. Haciendo esto reducimos la presión sobre el campo de la clave de acceso y repartimos algo mejor la responsabilidad de ingreso en ambos campos. También aumentamos radicalmente el tiempo necesario para adivinar los datos por fuerza bruta. No tendremos que controlar demasiado la longitud de dicho campo ya que no se repetirá su contenido en otras tablas, pudiendo permitir inclusive logins en forma de frases. Identificadores de acceso como "El mejor usuario que ha tenido este banco" no deberían extrañarnos y serían mucho más difíciles de adivinar.

Los hackers me han enseñado que si uno quiere saber el login o identificador de un usuario, en el 50% de las veces basta con saber la parte anterior al arroba (@) en su dirección de e-mail principal. Permitiendo o exigiendo cambiar el identificador en un caso de sospecha de intrusión la seguridad del sistema de ingreso aumentará radicalmente y esta premisa dejaría de ser cierta.

De todas  formas aclaro que tampoco es muy sano tener solamente dos factores de autentificación en un sistema de acceso, pero mucho menos lo es que uno de esos dos factores sea prácticamente público y permanente. Actualmente los factores de autentificación solicitados por empresas de certificación y de regulación están en el orden de cuatro o cinco incluyendo un factor externo a la aplicación. Sin embargo eso es tema para otro artículo.

Hasta la próxima!