La identificación correcta y segura de usuarios sigue siendo uno de los dolores de cabeza de la seguridad informática: pasan las décadas (que en informática son eones) y sigue sin haberse generalizado una solución mejor que la identificación mediante usuario y contraseña. Para nosotros, los humanos, es difícil recordar contraseñas y aún más disponer de una contraseña diferente para cada sitio. Los ordenadores tampoco nos están ayudando: los avances en el hardware han convertido en inseguras contraseñas que previamente no lo eran, lo que nos obliga a tener que recordar unas claves cada vez más largas y con alternancia de letras, números y signos. Algunos expertos proponen soluciones que dejan atrás la identificación mediante usuario y contraseña; mientras estas no se generalicen, expongo una solución que ayude a mitigar el problema.
Cuando introducimos la contraseña, la aplicación le aplica una función de hash o de cifrado simétrico y compara el resultado con el dato almacenado para el usuario: sólo si ambas cadenas de texto coinciden el usuario será validado. La razón de este proceder es que, por razones de seguridad, las contraseñas nunca se almacenan en forma de texto plano en el servidor; pues si un intruso logra acceder a la base de datos, ya no tiene ningún impedimento para acceder a las contraseñas de todos los usuarios.
Consulta SQL de usuario y contraseña que muestra cómo se almacenan las contrseñas
En un mundo teórico e ideal, se usaría una función de cifrado, pues ésta garantiza que sin la clave no se puede invertir, es decir, no se puede obtener el original a partir del texto cifrado. La contrapartida es que estas funciones consumen bastante CPU comparadas con ciertas funciones de hash. Esto no se notaría en una pequeña aplicación, pero cuando hay cientos de miles de usuarios validándose cada día, el consumo de tiempo de CPU puede impedir un tiempo de respuesta óptimo de ésta. Como «solución», lo habitual es emplear una función de hash, pues estas, generalmente, requieren menos cálculos. Ahora bien, éstas fueron creadas para usos diferentes al de la seguridad, por lo que la seguridad de las contraseñas se ve comprometida.
Aunque pueda parecer extraño, es la proliferación de las Unidades de Proceso Gráfico (GPU) lo que ha comprometido tanto la seguridad de las funciones de hash. Estos coprocesadores son el corazón de las tarjetas gráficas y están especializados en cálculos para gráficos 3D; es gracias a ellos que los videojuegos pueden calcular millones de triángulos por segundo, con sus texturas, etc. A día de hoy, tienen otras aplicaciones más oscuras, por ejemplo ataques de fuerza bruta1 contra hashes, y para hacer peor las cosas, con algoritmos especializados en aprovecharlas.
Otro debilitamiento viene dado por las vulnerabilidades descubiertas en los algoritmos de hash más utilizados. En primer lugar, la más grave afecta al veterano (1991) md5, aunque ya hace casi 13 años de su descubrimiento, a día de hoy se sigue usando para cifrar contraseñas pues algunos desarrolladores todavía desconocen que ha quedado descartada para la seguridad. En segundo lugar, a SHA-1 también le ha caído la suya, a pesar de que haber sido creado por la agencia nacional de seguridad estadounidense NSA. De todas formas, no olvidemos que estos algoritmos se crearon con objetivos diferentes al cifrado: la comprobación de la integridad de los datos y la firma de digital, por lo que no pidamos peras al olmo.
Algunos datos bastarán para que el lector se haga una idea de lo delicado de la situación: Un ordenador normal de sobremesa equipado con dos tarjetas gráficas ATI Raedon 7970, trabajando con contraseñas limitadas a los caracteres de un teclado inglés, números incluidos y con distinción de mayúsculas y minúsculas, puede generar en 45 minutos los hashes md5 de todas las contraseñas posibles de 6 caracteres, las de 7 en una hora y 47 minutos y en 465 días la de 8 caracteres. Limitando los caracteres sólo a las letras (con distinción de mayúsculas y minúsculas) y los números, como sucede con las contraseñas más habituales, para 6 caracteres sólo hacen falta 3 segundos, 4 minutos para 7 caracteres, 4 horas para 8 y 10 días para 9 caracteres. He aquí una tabla con resultados para otros algoritmos donde se puede observar que, si bien obtienen mejores resultados, no son lo suficiente, pues no olvidemos que se pueden poner muchas tarjetas a trabajar en paralelo y, además, la nube no solo proporciona soluciones de almacenamiento, sino también de cálculo para procesos intensivos.
Tarjetas gráficas trabajando en paralelo: Esto no sólo es el paraíso gamer.
Estos ataques se vuelven mucho más dañinos si, en vez de generar las claves con caracteres al azar, hasta probar todas las combinaciones posibles de n caracteres, para después pasar a las de n + 1, se emplea un diccionario formado por miles de contraseñas habituales. Las combinaciones fácilmente se pueden ampliar añadiendo caracteres a las palabras del diccionario: se pueden añadir, por ejemplo, las cadenas «1», «12», «123», etc. a todas las palabras, de manera que si el diccionario contiene la palabra «boby», es factible que el usuario dueño de un perro con este nombre lo pase mal. Estos ataques son menos brutos y resultan mucho más eficientes que ir probando todas las combinaciones posibles de caracteres. En definitiva, contraseñas como «1a2N567mJ» o «andres123» resultan tan solo un poco mejores que la célebre y más usada de todas: «123456«.
El programador que esté leyendo esto, podría pensar que estos cálculos son demasiado pesimistas y que no afectan a su software porque usa una salt (también conocida como semilla). Esta es una cadena de texto que se concatena a la contraseña del usuario antes de aplicar la función de hash, tanto cuando se va a almacenar en la base de datos como en el proceso de validación. La debilidad de este sistema consiste en que un atacante que ha logrado comprometer la seguridad de la base de datos, muy probablemente también habrá accedido al código fuente de la aplicación y, por lo tanto, conocerá la semilla, por lo que la privacidad de los usuarios volverá a depender exclusivamente de la fortaleza de su contraseña. Ahora bien, si se genera aleatoriamente una salt por cada contraseña, entonces sí que un ataque por fuerza bruta puede ser inviable.
<?php
hash("sha1", "Talvez este salt mejora la seguridad, o no..." . $password);
Para proteger a los usuarios de esta nueva realidad se les sugiere – y a veces se les obliga – que sus contraseñas estén formadas por minúsculas, mayúsculas, números y signos de puntuación y que además tengan una extensión mínima, ésta última en aumento a medida que avanza el hardware. El gran problema de estas contraseñas es que son difíciles de recordar; si además se le añade la recomendación de tener una diferente por cada sitio, para evitar que si un atacante logra obtener la de uno pueda acceder a todos los demás, la misión de recordarlas todas es un sobresfuerzo. En la misma línea de reforzar la seguridad, van las recomendaciones de no guardar las contraseñas en ningún sitio y renovarlas periódicamente. Ejemplos de contraseñas seguras son:
- o{0Or.-49q]gMt-
- Pr&)6gm1$_dvfZ9
Los usuarios necesitan de la informática que les facilite la vida y les abra nuevas posibilidades, no que les añada más problemas, pero hay una solución. Los humanos, a diferencia de los ordenadores, somos realmente malos memorizando estas cadenas de texto. Esto es debido a que carecen de significado, nosotros asociamos ideas, conceptos, mientras que para un ordenador la semántica es irrelevante: no sabe de información, «sólo» maneja datos (pero en una cantidad y una velocidad a años luz de nuestra capacidad). Entonces, trabajemos como nos resulta cómodo a nosotros y hagámoselo difícil a los malos. A continuación algunas contraseñas tan seguras como las anteriores, o más, y mucho más fáciles de recordar:
- En un lugar de la Mancha,
- ¡Cuatro días con sus noches!
- A ver cuándo vuelven a robarles todos los datos de sus usuarios…
La idea es que la frase tenga cierta relación con el sitio web al que da acceso. Así, por ejemplo, la última es especialmente fácil de recordar como contraseña para Yahoo. En todo caso, si nuestra memoria no es muy buena, tener escrito en algún lugar «seguro», un listado con los sitios web y por cada uno la idea asociada para recordar la frase, es más fiable que escribir directamente las contraseñas. Si además, en las frases se incluyen letras y signos propios de nuestro idioma, que no están en los 128 caracteres de la tabla ASCII (los americanos no pensaron en nuestro idioma), les estamos poniendo las cosas realmente difíciles a los malvados, pues los diccionarios están generalmente orientados a la esfera anglosajona.
Desafortunadamente, no se puede aplicar esta solución a todos los sitios web, pues algunos no aceptan el espacio como carácter válido en la contraseña u obligan a usar al menos un número. Si la norma obliga a usar algún signo no es problema pues una frase fácil de recordar sigue siéndolo aunque se le añada puntuación. En mi opinión, estas normas en las contraseñas de los usuarios son una mala idea, pero lamentablemente algunos sitios, una minoría, las tienen.
Los sistemas alternativos a las contraseñas consistentes en guardar bio datos presentan problemas de privacidad: en la identificación facial o de retina, por ejemplo, el almacenamiento de estos datos permitiría, a quien disponga de ellos, la identificación de ciudadanos en cualquier sitio donde se les haya grabado. Sin llegar a estos extremos, que a día de hoy todavía pueden parecer un poco de ciencia ficción (aunque cada vez menos), actualmente ya disponemos de la verificación en dos pasos para reforzar la validación de usuarios. Este sistema es, además, compatible con la solución aquí expuesta, pues generalmente el primer paso consiste en la introducción de la contraseña.
En conclusión, mientras no se halle una solución al problema que la informática lleva arrastrando desde que, en sus albores, uno de sus primeros sistemas necesitó que un usuario se validara, vamos a seguir usando contraseñas. Una clave que hace 10 años todavía era segura, ya no lo es. Para evitar el infierno de tener que recordar un número de contraseñas creciente, de una extensión, a la vez, también creciente, espero que la idea que aquí expongo, y que salió del blog de un empleado de Microsoft, se siga expandiendo, porque la seguridad y la privacidad no es tema baladí.
Editado el 9/1/2018:
A modo de ejemplo de los riesgos que para la privacidad tiene el almacenamiento de bio datos, sirva esta noticia que informa acerca de las continuas filtraciones que sufre el sistema con más datos biométricos almacenados en el mundo. Por menos de 10 dólares se puede obtener información de una base de datos formada por más de mil millones de usuarios.