intive Argentina Blog

La mejor contraseña del mundo es Goku, porque Goku es muy fuerte

Como decía mi abuelo, la seguridad informática es como la fecha de caducidad de la leche: hasta que la heladera huele feo, no consideramos importante revisar si la leche venció. Claro, mi abuelo no sabía mucho de seguridad informática, a él simplemente le encantaba el café con leche. Pero tenía fincas ganaderas y agrícolas y, salvando las distancias, era importante que estuvieran seguras.

Los equipos de desarrollo y operaciones se vuelven responsables de su aplicación (o de su finca); en un entorno ágil la seguridad suele quedar relegada a un título de una tarea en el backlog: ”Agregar seguridad”. Su prioridad es muchas veces igual a cero. Hasta que es muy tarde, a veces lamentablemente tarde, y la leche venció.

En otro artículo tocamos un poco el tema de los elementos que consideramos claves para asegurar una buena política de seguridad informática. En este artículo, en cambio, hablaremos de “cómo accedemos” y “cómo autenticarnos”.

“Cómo accedemos”

Cuando decimos “cómo accedemos”, nos referimos a cuál es el medio a través del que vamos a tomar control de un servicio. Por ejemplo, si para poder acceder al mismo lo hacemos por medio de una página web, una conexión remota, o una aplicación desktop. En algunos de esos casos, la administración del servicio está sumamente expuesta en cuanto a su seguridad. Algunos ejemplos son:

  • Para poder acceder al administrador de la aplicación basta con sólo agregar en la url “/admin”. En este caso un atacante podría empezar a utilizar diferentes técnicas para ingresar a un área con permisos elevados.
  • Los puertos para conexiones remotas de los servidores productivos están abiertos a cualquier conexión. En algunos casos, incluir una protección para evitar acceder al administrador del servicio o a otro recurso que se considere confidencial e importante puede entorpecer la labor del equipo. Más si este se encuentra disperso geográficamente. En esta oportunidad tendremos que hacer un balance acerca del riesgo y de la importancia del servicio contra la complejidad de cómo acceder.

“Cómo autenticarnos”

Sobre autenticación, lo primero que llega a la mente es usuario y/o clave. Entonces me preguntan sobre contraseñas seguras, y siempre me acuerdo de aquella famosa escena de la película Spaceballs (1987) del director y actor Mel Brooks.

Aunque esto parezca una broma o una anécdota jocosa, muchas empresas por descuido utilizan contraseñas que son fácilmente adivinadas, o utilizan las contraseñas por defecto de sus productos. Entonces nos encontramos con claves como “password”, “12345”, “qwerty” o “admin”. Inclusive, por muchos años el código para destruir la humanidad era “00000000”.

Las contraseñas no necesariamente tienen que ser sumamente complejas, podrían ser memorizables; pero debe existir una cultura de evitar compartir mi usuario y contraseña a otros miembros del equipo. Principalmente cuando el usuario que se comparte tiene permisos elevados que pueden afectar a otros usuarios, eliminar recursos o alterar la continuidad del servicio. En tal caso se deben tomar medidas como utilizar una autenticación multi factor (“Multi Factor Authentication” en inglés, o también conocida como MFA), realizar una restricción por IP o definir alguna otra capa de protección. Claro está, ninguna de esas medidas debe afectar la capacidad de respuesta a un usuario.

En nuestras aplicaciones, también tendremos usuarios y contraseñas cuyo uso es para que un sistema se conecte a otro. Normalmente esos usuarios tienen acceso a modificar información y, parte de su naturaleza es impedir que un usuario humano se autentifique con las mismas credenciales. En otro artículo del blog se puede analizar cómo implementarlos en un ambiente de desarrollo y producción.

Algunos consejos concretos acerca de autorización y autenticación son los siguientes:

  • Tu usuario y contraseña son como el cepillo de dientes, no se lo deberías prestar ni a tu mejor amigo.
  • Las contraseñas complejas no dan mayor seguridad, pero usar contraseñas fáciles y comunes es una pésima idea. Algunas de las contraseñas más usadas se muestran en reportes anuales como el de Keeper.com.
  • Cuando exista necesidad de enviar accesos a otro usuario, el chat y el correo no son medios confiables. Igualmente, retenerlos en el correo o en archivos de texto plano no es una buena idea, ya que existe una mayor facilidad para robarlos.
  • Nunca se debe exponer al mundo un servicio de base de datos o de acceso remoto sin ningún tipo de filtro.
  • Cuando se utiliza un dispositivo para un ambiente productivo se recomienda evitar usar las credenciales por defecto, existen sitios web que recopilan estas credenciales. Por ejemplo, Default Password.
  • Como cultura de empresa, se debe evitar que el equipo use cuentas personales para desarrollo, esto evitará que sea complicado retirar las credenciales a un usuario si abandona la compañía o cambia de proyecto.
  • Cuando un nuevo miembro tiene que salir del proyecto es importante que exista un proceso de salida, que permita retirar cualquier acceso que tenga dentro del proyecto.

La seguridad es una cultura que se establece desde el principio del proyecto. Por eso es importante tomar en cuenta todas estas recomendaciones, y asignarle al tema un valor mayor a cero en la planificación de las primeras fases. La clave está en revisar la heladera, antes de que huela feo.

Rodolfo Cordero

Rodolfo Cordero es desarrollador en la compañía desde junio de 2016. Es Licenciado en Desarrollo de Software, graduado de la Universidad Latina de Costa Rica, país del cual es oriundo. Asiduo lector y melómano, hizo cursos de coctelería y barismo, habilidades con las que deleita al staff de intive-FDV en los afters organizados por la compañía.

2 comentarios