Siempre he sido de la opinión que no hay que ser un paranoico de la seguridad, simplemente intentar que todo lo que se hace debe ser lo más seguro posible: «La seguridad no es un lema, es una forma de vida» y por esta razón, cuando vi el siguiente gráfico de tiempos que tardaría una máquina en conseguir una contraseña, me entró la curiosidad sobre qué se puede hacer normalmente para evitarlo.
Visto lo visto, con las GPUs que hay hoy día y la potencia de cálculo que tienen los sistemas cloud comerciales, crear una contraseña de menos de 12 caracteres es básicamente instalar una bomba de relojería a la espera de que venga un bot con algo de tiempo y acceda a nuestros sistemas.
Uno puede pensar en contraseñas largas y complejas con más de 15 caracteres, mayúsculas, números, símbolos, alguna coma, un signo dólar y alguna Ñ, pero a la vista de la cantidad de contraseñas que hay que escribir, al final lo mejor y más cómo para evitar repetir la misma contraseña, es utilizar una herramienta que sirva como «llavero» y que contenga las contraseñas que utilizamos, tan grande y complejas como queramos, de manera que no haya que recordarlas.
Herramientas llavero
Suelo utilizar la herramienta KeePass que permite crear varias bases de datos cifradas con las contraseñas que uso para diferentes motivos (empresa, servidores, personal, clientes, loqueseteocurra, etc.) y tras una contraseña maestra para cada base de datos, poder acceder a toda la lista de accesos con total seguridad. Esas bases de datos están en archivos cifrados dentro del sistema de ficheros local, por lo que la seguridad es mucho mejor que tenerlo en un Post-it en el monitor, en una libreta de papel o en una hoja Excel (ya que ésta última no suele ir cifrada).
El problema de este tipo de herramientas es que, cada vez que hace falta acceder a un sitio, hay que abrir la aplicación, meter la contraseña, buscar el acceso que necesitas y gracias al «copy+paste«, poder pegar la contraseña y así, autentificarte de forma segura. No es la fórmula más práctica. (aunque luego explicaré cómo soluciono esto).
2 contraseñas: la segunda, varía con el tiempo
No obstante, investigando un poco cómo lo harán en las grandes empresas de seguridad, recuerdo el caso de un amigo que trabaja en Google y que, cuando entró, en el pack de bienvenida, le entregaron además de un montón de merchandising, un portátil y algunas cosas más, una Yubikey: una mochila USB que sirve como sistema de dos pasos automático.
Introduces el login, la contraseña y cuando se comprueba que es correcto, además te pide un código que, en lugar de enviarte un código al móvil, sólo tienes que «tocar» la Yubikey y ésta rellena la parte del código de segundo paso. Si alguien te roba la contraseña no podrá hacer nada, ya que no tendrá tu móvil o la mochila USB para saltarse el segundo paso, y la Yubikey suele ir como una llave más del llavero, por lo que siempre la llevas contigo, igual que tus llaves de casa.
El sistema de autentificación de dos pasos siempre me ha parecido muy interesante desde que hace muchos años (hace más de 13 años) un amigo belga me enseñaba cómo utilizaba la autentificación en dos pasos para sacar dinero de su banco. Un aparato especial le generaba un código que tenía que meter como «segundo pin de seguridad«.
Ahora se ha visto que el hecho de enviar un SMS al móvil no es lo más seguro, ya que hay quien incluso te clona la tarjeta SIM para poder recibir el mensaje y hacerte verdaderos desfalcos (lo que significa que ya tienen tu usuario y contraseña y sólo les para esa doble autentificación), así que me puse a mirar el sistema de Google para el tema de generar el código necesario.
A falta de tener una Yubikey de esas para hacer pruebas, tengo un móvil con el que generar los códigos de segunda autentificación, y una lista interesante de servidores personales y máquinas a las que accedo normalmente por SSH, voy a ver cómo dotarla de algo más de seguridad.
Autentificación de dos pasos para acceder por SSH al servidor
Para ello, se me ocurrió usar la doble autentificación (o autenticación, que es lo mismo) en el acceso SSH, lo único que, en lugar de enviar un SMS, voy a utilizar una aplicación en el móvil que genere un código de seguridad válido gracias a un token.
Para esto existen dos aplicaciones comunes: GoogleAuthentication y FreeOTP (las dos funcionan igual, aunque utilizaré FreeOTP por ser software libre y darme algo más de confianza).
Lo que vamos a hacer será configurar el sistema de acceso por SSH, de manera que una vez introduzca la contraseña, se añada una verificación extra (de ahí lo de «los dos pasos») que me solicite un número variable que sólo tendré yo gracias a la aplicación FreeOTP.
1. Instalación de los paquetes necesarios
Para configurar esto en una Debian, lo primero es instalar un paquete básico:
~$ sudo apt update~$ sudo apt install libpam-google-authenticator
Este «libpam-google-authenticator» es uno de los módulos del sistema PAM (Pluggable Authentication Modules) de manera que se ejecute después de la autentificación estándar para poder permitir el acceso.
2. Configuración del SSH y del PAM
Acto seguido, vamos a editar el archivo de configuración del demonio SSH /etc/ssh/sshd_config para decirle que queremos utilizar el sistema de módulos PAM.
Para ello, nos aseguramos que tenemos estas opciones habilitadas:UsePAM yes
ChallengeResponseAuthentication yes
Nada más asegurarnos de esto, editamos el archivo: /etc/pam.d/common-auth donde añadiremos las siguientes líneas:
# Autentificacion OTP mediante Google Authenticator
auth required pam_google_authenticator.so
3. Instalar la aplicación FreeOTP o GoogleAuthenticate.
En mi caso, utilizo FreeOTP que es software libre y se encuentra tanto en Google Play como en la App Store.
Una vez instalado, y ejecutado, hay que dar permisos para utilizar la cámara, ya que tendremos que escanear un código QR que nos saldrá por pantalla con el «token» del servidor al que nos vamos a conectar y que se utilizará para generar las contraseñas en función del tiempo.
Ahora bien, nos logueamos por SSH con el usuario que queramos y ejecutamos el comando:
~$ google-authenticator
Do you want authentication tokens to be time-based (y/n) y
Tras esto, nos saldrá por pantalla un código QR que tendremos que escanear desde nuestra aplicación.
Le decimos que «yes» a todo… y guardamos bajo llave los códigos de «emergencia» por si no tenemos nuestro móvil a mano para generar la clave. (Estos códigos sólo se pueden utilizar una vez cada uno, por lo que hay que guardarlos muy bien o volver a generar el token)
4. Reiniciar el servidor para aplicar cambios
Vale, nuestro usuario ya tiene habilitado el token de seguridad, ahora lo último que tenemos que hacer es reiniciar el servidor SSH para que utilice el sistema PAM con el módulo que hemos añadido.
~$ systemctl ssh restart
5. Comprobamos el acceso
Ahora que ya está todo funcionando, volvemos a acceder con el mismo usuario que hemos activado el token y veremos que una vez introducida la contraseña, nos pedirá un código.
En este momento, habrá que buscar el código en la aplicación.
Tendremos 30 segundos para introducir el código tras lo cual, tendremos acceso al sistema.
En resumen
Vale, lo primero… muy intuitivo no es, y rápido tampoco, pero si es más seguro que un acceso normal.
El hecho de tener que acceder a una aplicación del móvil para poder acceder a nuestra cuenta, no es algo que sea muy práctico si nos pasamos el día accediendo a ella, de ahí la utilidad de la Yubikey. Para este tipo de cosas está la autorización de llave pública y de esta manera evitamos tener que meter contraseñas (incluso utilizando la autentificación que hemos visto) y accedemos rápidamente al sistema que queramos validando directamente la clave de nuestro ordenador con el servidor.
Por lo que, para sistemas en los que necesitemos un extra de seguridad, seguramente sea una buena fórmula.
Si aplicamos este sistema (OTP – One-Time-Password) a otros servicios, posiblemente aumentaremos bastante la seguridad. Como decía al principio, la idea no es ser un paranoico de la seguridad, si no aprender a ser seguros en todo lo que hagamos.