Cómo las empresas pueden reforzar la seguridad de las contraseñas: Krebs sobre seguridad

Violaciones de contraseña separadas la semana pasada en LinkedIn, eHarmony y Last FM expuso millones de credenciales y, una vez más, planteó la cuestión de si alguna empresa puede obtener la seguridad de contraseña correcta. Para comprender más acerca de por qué las empresas siguen cometiendo los mismos errores y qué podrían hacer de manera diferente para evitar futuras debacles de contraseñas, entrevisté a Thomas H. Ptacekun investigador de seguridad con Matasano Seguridad.

Ptacek es solo uno de varios investigadores extremadamente inteligentes con los que he estado hablando sobre este tema. A continuación se muestran algunos fragmentos de una conversación que tuvimos la semana pasada.

BK: solo estaba leyendo un artículo por Eric Chabrow, que señaló que LinkedIn, una empresa multimillonaria que posee información personal sobre algunos de los ejecutivos más importantes del mundo, no tiene un director de información ni un director de seguridad de la información. ¿Es demasiado pedir que una empresa como esta se tome la seguridad lo suficientemente en serio como para hacer un mejor trabajo protegiendo y asegurando las contraseñas de sus usuarios?

Ptacek: No existe una correlación entre cuánto dinero tiene o ingresa una empresa o servicio, o si es gratis o no, y qué tan buenas son sus prácticas de almacenamiento de contraseñas. Nadie entiende esto bien. Creo que es un problema de los desarrolladores generalistas que escriben sistemas de almacenamiento de contraseñas. Pueden ser buenos desarrolladores, pero casi nunca son especialistas en dominios de seguridad. Hay muy pocos buenos desarrolladores que también sean especialistas en dominios de seguridad. Entonces, si es un desarrollador inteligente y talentoso, pero no un especialista en el dominio de la seguridad, y tiene que armar un sistema de almacenamiento de contraseñas, incluso si es solo MD5, para ti eso es una tecnología extraterrestre. Eso es un algoritmo criptográfico. Puedes decirle a tu jefe que es un hash criptográfico. Te sientes bien por el hecho de que estás almacenando contraseñas en un hash criptográfico. Pero debe ser un experto en el dominio para saber que el término hash criptográfico en realidad no significa mucho.

BK: ¿Por qué el hash criptográfico no significa mucho? Tal vez LinkedIn no debería haber estado usando una simple función de hash criptográfico SHA-1, pero ¿no deberían los desarrolladores buscar proteger sus contraseñas con un algoritmo criptográfico sólido?

Ptacek: El mecanismo básico por el cual SHA-1 las contraseñas están descifradas, o MD5 o SHA-512, no importa qué algoritmo use, no ha cambiado desde principios de la década de 1990. Tan pronto como apareció el código para implementar SHA-1, también estuvo disponible para Juan el Destripador y otras herramientas para descifrar contraseñas. Es un concepto erróneo muy común, incluso entre la gente de seguridad, que el problema aquí es usar SHA-1. No habría importado en absoluto si hubieran usado SHA-512, no estarían mejor en absoluto.

BK: Escuché a personas decir, sabes que esto probablemente no hubiera sucedido si LinkedIn y otros hubieran salteado las contraseñas, o agregado algo de aleatoriedad a cada una de las contraseñas, lo que obligó a los atacantes a gastar más recursos para descifrar los hash de contraseña. ¿Estás de acuerdo con eso?

Ptacek: Ese es en realidad otro concepto erróneo, la idea de que el problema es que las contraseñas no tenían sal. Contraseñas de UNIX, y han sido saladas para siempre, desde los años 70, y han sido descifradas para siempre. La idea de una sal en su contraseña es una solución de los años 70. En los años 90, cuando la gente irrumpía en los servidores UNIX, robaban el archivo de contraseña oculta y lo descifraban. Invariablemente, cuando perdía el servidor, perdía las contraseñas de ese servidor.

B.K.: Está bien. Entonces, si la debilidad no está en la fortaleza del algoritmo criptográfico, y no en la falta de sal agregada a las contraseñas cifradas, ¿cuál es la respuesta?

Ptacek: En el caso de LinkedIn, y con muchos otros sitios, el problema es que están usando el tipo de algoritmo incorrecto. Usan un hash criptográfico, cuando necesitan usar un hash de contraseña.

BK: Voy a morder: ¿Cuál es la diferencia?

Ptacek: La diferencia entre un hash criptográfico y un hash de almacenamiento de contraseña es que un hash criptográfico está diseñado para ser muy, muy rápido. Y tiene que ser porque está diseñado para usarse en cosas como IP-sec. Paquete por paquete, cada vez que un paquete llega a una tarjeta Ethernet, estas son cosas que deben ejecutarse lo suficientemente rápido como para no agregar latencias perceptibles al tráfico que pasa a través de los enrutadores de Internet y cosas por el estilo. Entonces, el objetivo principal del diseño de los hash criptográficos es hacerlos ultrarrápidos.

Bueno, eso es lo contrario de lo que quieres con un hash de contraseña. Desea que un hash de contraseña sea muy lento. La razón de esto es que un usuario normal inicia sesión una o dos veces al día si es así, tal vez escribe mal su contraseña y tiene que iniciar sesión dos veces o lo que sea. Pero en la mayoría de los casos, hay muy pocas interacciones que el usuario normal tenga con un sitio web con un hash de contraseña. Muy poca parte de los gastos generales en la ejecución de una aplicación web proviene del hash de su contraseña. Pero si piensa en lo que tiene que hacer un atacante, tiene un archivo lleno de hashes y tiene que probar miles de combinaciones de contraseñas contra cada uno de esos hashes. Para ellos, si haces que un hash de contraseña tome más tiempo, eso es un asesinato para ellos.

Entonces, si usa un hash de contraseña moderno, incluso si tiene aceleración de hardware, incluso si diseñó sus propios circuitos para hacer hash de contraseña, hay hash de contraseña modernos y seguros que tomarían cientos o miles de años para probar contraseñas.

BK: ¿Puede darme un ejemplo de la diferencia entre el tiempo y los recursos necesarios para descifrar, por ejemplo, una contraseña SHA-1 frente a un buen hash de contraseña?

Ptacek: Supongamos que tiene una contraseña razonablemente correcta y está utilizando un hash SHA-1 aleatorio con sal. Puedo, listo para usar, construir un sistema que probará muchas, muchas decenas de miles de contraseñas posibles por segundo. Puedo ir a Best Buy o lo que sea y comprar una tarjeta disponible que haga eso, y el software para hacerlo es de código abierto.

Si en cambio estuviéramos usando algo como Bcriptque habría sido simplemente la diferencia de usar un diferente [software] biblioteca cuando construí mi aplicación, puedo configurar Bcrypt para que un solo intento, para probar si mi contraseña era «contraseña» o «himom», solo esa prueba podría tomar cien milisegundos. Así que de repente estás hablando de decenas de intentos por segundo, en lugar de decenas de miles.

Lo que hace con un hash de contraseña es diseñarlo de la manera opuesta a la que diseñaría un hash criptográfico estándar. Un hash criptográfico quiere hacer la mínima cantidad de trabajo posible para llegar a un resultado seguro. Pero un hash de contraseña quiere diseñarse deliberadamente para hacer la máxima cantidad de trabajo.

¿Puede explicar en términos sencillos qué es lo que hace que un hash de contraseña como Bcrypt tarde tanto en descifrarse?

Ptacek: Es similar a si dijiste, tomemos la contraseña SHA-1, pero en lugar de solo usar SHA-1, ejecutemos SHA-1 en sí mismo miles de veces. Entonces, tomaremos la salida de SHA-1 y se la devolveremos a SHA-1, y lo haremos miles y miles de veces, y solo sabrá si el hash de su contraseña es correcto, cuando mire el resultado de esa ejecución número 1000 de SHA-1. Entonces, para que el hash de contraseña funcione, debe ejecutar el algoritmo 1,000 veces para cada intento. Esa es más o menos la táctica que toman los hashes de contraseña modernos y seguros. Estos son algoritmos que están diseñados para que no puedas llegar al resultado sin mucho, mucho trabajo. Quiero decir, estamos hablando de 100 milisegundos [one-tenth of a second] vale la pena trabajar en hardware moderno para obtener los resultados de un solo intento de contraseña.

BK: Entonces, ¿cuál es el truco aquí? ¿Son estos sistemas de hashing de contraseñas más difíciles o más caros de implementar?

Ptacek: Es un problema de conocimiento. Esto es más fácil de implementar que construirlo usted mismo. Si lo construye usted mismo, se necesita una buena cantidad de esfuerzo. Mientras que las bibliotecas para proteger los hashes de contraseña, justo donde los colocas, es como una llamada de función. Y todos son gratis. No hay que preocuparse por las patentes ni nada por el estilo.

La aplicación web aumenta muy, muy levemente sus costos. Una cantidad imperceptible. Pero inteligentemente, lo han hecho de una manera que explota drásticamente los costos para los atacantes. Si un intento de contraseña normal toma un microsegundo [one millionth of a second]– pero una prueba de contraseña bcrypt toma 10 milisegundos [a hundredth of a second] – también podrías rendirte. Tomará años y años.

Digamos que tenemos una aplicación web que perdió 10 millones de hashes de contraseña, pero son contraseñas cifradas. Entonces, creo que en el último volcado que vimos del volcado de LinkedIn, se descifraron alrededor de tres millones de esas contraseñas. Fue realmente rápido y fácil ver si su contraseña había estado allí. En este caso, si perdimos 10 millones de contraseñas cifradas, en lugar de que 3 millones de ellas se publiquen y se comprometan, es posible que vea decenas o cientos de contraseñas de usuarios comprometidas. Porque tal vez podría buscar efectivamente cada contraseña que fuera «contraseña», pero ciertamente ya no podría ejecutar un diccionario contra cada contraseña allí.

BK: ¿No es probable que muchas empresas que confían en hashes criptográficos no hayan cambiado a hashes de contraseñas porque podría ser perjudicial, costoso o difícil de hacer? ¿Estás de acuerdo o hay otros problemas que se interponen en el camino aquí?

Ptacek: En cierto punto, el costo de migrar eso es increíblemente caro. Y asegurar aplicaciones web que son tan complejas como LinkedIn es un problema increíblemente difícil. Al mismo tiempo, tratar de encontrar talento para asegurarse de que lo están creando correctamente… simplemente no hay suficiente talento en seguridad de aplicaciones. Es difícil contratar a personas que saben de lo que hablan. Hay mucho conocimiento a granel que se sustituye por experiencia real. Puede encontrar muchos desarrolladores generales que comparten su sabiduría sobre cómo desarrollar aplicaciones seguras, pero estos son, en general, solo desarrolladores generales que intentan ser inteligentes, no son personas que realmente saben de lo que están hablando.

Para mí, el problema fundamental son las contraseñas. Las personas deberían usar mejores algoritmos de almacenamiento si van a infligir contraseñas a sus usuarios. Deberían hacer un mejor trabajo. Pero la respuesta real es cosas como la autenticación de dos factores con teléfonos inteligentes. La autenticación de dos factores me parece la respuesta. Creo que dentro de diez años este será un enfoque común.