Breve e incompleta historia de las contraseñas, aliados y enemigos (II)

Vale, pero entonces ¿Cómo deben ser las contraseñas para que sean seguras? Hemos de tener en cuenta algunos factores. En primer lugar, la contraseña no es más que un parámetro más que se le va a pasar a una función que va a generar el hash, que a su vez se depositará en la base de datos. Por lo tanto, si un atacante posee el conocimiento o datos para derivar u obtener el resto de los parámetros, su ataque se restringe a dar con una cadena que finalmente nos devuelva el hash deseado. Así, la contraseña es un valioso recurso que va a influir a su manera en la seguridad o resistencia al ataque.

Rara vez será que una contraseña se almacena cifrada mediante clave simétrica. ¿Alguna vez habéis recibido un correo de recordatorio de contraseña con la contraseña en claro? Pecado capital. Otro aspecto importante es el universo de caracteres permitidos y su mensaje sospechoso de “no utilizar caracteres que no sean alfanuméricos” o “su contraseña tiene caracteres no válidos”. Esto indica que las cosas no se están haciendo de forma óptima.

Una cadena tiene dos dimensiones: número de caracteres que la componen o longitud, y número de caracteres que podemos elegir. ¿Juegas a la lotería? Si compras un número, tal y como el 01729, sabemos que es un número de cinco cifras y que cada cifra puede ser una de diez posibles. Es decir, estamos ante una probabilidad de uno entre cien mil. Este concepto es exactamente el mismo que opera detrás de la longitud y número de caracteres posibles para una contraseña (formalmente, el espacio de búsqueda). Cuantos menos caracteres dejemos a un usuario, más billetes de lotería le estamos comprando a un atacante. 

Por otro lado, podríamos preguntarnos, ¿por qué se quiere evitar el procesamiento de ciertos caracteres? Respuesta: probablemente han implementado un control defensivo. La intención no es mala, puesto que se quiere evitar una inyección (por ejemplo, SQL) cuando se está introduciendo una contraseña. Pero, y de nuevo se levantan las sospechas, no estamos en la etapa adecuada.

Una contraseña no debe tocar base de datos así; recordemos, solo se almacena su hash. Luego, a una función hash le debe dar igual que como contraseña tengamos un “delete database”, no se va a intoxicar ni va a borrarnos la base de datos.

Las únicas restricciones que debemos imponer a un usuario son, precisamente, para que ofrezcan el efecto contrario: que la contraseña sea robusta. Longitud, no máxima sino mínima, inclusión de caracteres más allá de los alfanuméricos y algo importante: que no sea una contraseña “habitual”. Para esto último, disponemos de librerías y listas que analizan la predictibilidad de la contraseña propuesta por el usuario. Por ejemplo, el clásico “12345” o “qwerty”.

Una contraseña para gobernarlas a todas

El gran dilema al que se enfrenta el usuario con conocimientos medios de informática es el siguiente: “Dispongo de unos 30-40 sitios webs en los que tengo cuenta, ¿cómo recuerdo la contraseña de cada uno de ellos?” El flujo de pensamiento de un usuario (de cualquier usuario) es el mismo que el del agua: continuar por el camino que ofrezca menos resistencia. Por supuesto, la respuesta es: “una contraseña que recuerde fácilmente y que sea la misma para todos y cada uno de los sitios en los que tengo cuenta”.

Precisamente, las listas de contraseñas más usadas se nutren de este vicio perverso. Así, aunque tengamos una función hash robusta, una sal perfecta y cifremos los hashes con una clave simétrica secreta y protegida, el eslabón débil seguirá siendo la contraseña del usuario, el aporte vago. El parámetro imperfecto.

Ayudar al usuario es ponerle trabas y esas trabas es un aporte negativo al índice de usabilidad del sitio. Mal balance. Por lo tanto, más que obstáculos se han de crear alternativas solventes. Una de ellas es la centralización de las contraseñas en la forma de gestores. Es decir, generan, proponen, almacenan y disponen de estas cuando sean necesarias.

Ya sean integrados en el navegador, como hemos visto por aquí, o en forma de software de terceros, un gestor de contraseñas, en su forma básica, nos permite obtener un muy razonable equilibrio entre seguridad y comodidad. La única contraseña que debemos recordar será la contraseña maestra o frase de paso necesaria para descifrar el contenido. Eso sí, el gestor es un punto de fallo único: se pierde la base de datos, se pierden todas y cada una de las contraseñas. Cambiemos el verbo “perder” por “comprometer” y el asunto se torna más trágico aún. Otro hecho sobre el que debemos dejar constancia aquí, vinculado en la mala práctica de reutilizar las contraseñas es que los atacantes no se limitan a usarlas sobre el sitio o servicio al que están ligadas. Efectivamente, esas mismas credenciales son puestas a prueba en otros sitios en los que el usuario comprometido posee una cuenta asociada.

El segundo factor

El plan B. Cuando todo está perdido ¿cómo evitamos que se use esa credencial robada o derivada del hash? Poniendo otra traba más al atacante. Protegemos el inicio de sesión con un nuevo anillo de seguridad, pero que esté basado en otro tipo de autenticación. Recordemos: lo que sabemos, tenemos o somos.

Los códigos de un solo uso, el generador de códigos pseudo-aleatorios temporales, la lectura de la huella digital, etc. Cada vez nos vamos acostumbrando más a asociar el inicio de sesión a otra cerradura adicional. Incluso es una medida que sacrifica algo de seguridad en pro de la comodidad. Por ejemplo, exigir el segundo factor de seguridad cuando iniciamos sesión en un nuevo dispositivo o navegador o posición geográfica.

No es la panacea, de acuerdo. Pero consigue hacer su función sin incomodar mucho al usuario y, aunque aun sigue siendo un opt-in, es un mecanismo que vuelve a ser sencillo y cómodo de implementar (hay disponibles decenas de librerías orientadas a la tarea) que cada vez está más presente en los sitios y aplicaciones web que no son top players.

En este sentido, desde ElevenPaths, pensamos cómo mejorar la experiencia de uso del segundo factor de autenticación con una propuesta original, llevando este modelo mucho más allá: ¿Qué mejor compañero de una cerradura que un cómodo pestillo? Latch nos permite, no solo poseer un segundo factor de seguridad, sino algo más potente: desconectar la autenticación cuando esta no es necesaria. Posee plugins y SDK para numerosas aplicaciones y lenguajes de programación, incluso posee su propio gestor de TOTP para crear tokens de segundo factor de autenticación. En la parte cliente, existen aplicaciones para todas las principales plataformas móviles: Android, iOS, Blackberry y Windows Phone.

Coda

Las contraseñas no dejan de ser una mala solución para un problema que aparenta ser simple. El compromiso es que aunque hoy en día los sistemas más fiables y seguros que existen, o bien no son cómodos de usar, o requieren de un despliegue y recursos que no compensa el riesgo que se asume.

Así pues, con estas compañeras de viaje, lo mejor que podemos hacer es anteponer las mejores prácticas disponibles, revisar los controles respecto a los avances existentes y cuidar que no aparezcan grietas que terminen por derrumbar nuestro trabajo. Recordemos la frase tan trillada: la seguridad no es un fin, es un proceso. Y añadimos: interminable.

También te puede interesar:

» Breve e incompleta historia de las contraseñas, aliados y enemigos (I)