Curso MIT "Seguridad de sistemas informáticos". Lección 17: Autenticación de usuario, Parte 1

Instituto de Tecnología de Massachusetts. Conferencia Curso # 6.858. "Seguridad de los sistemas informáticos". Nikolai Zeldovich, James Mickens. Año 2014

Computer Systems Security es un curso sobre el desarrollo e implementación de sistemas informáticos seguros. Las conferencias cubren modelos de amenazas, ataques que comprometen la seguridad y técnicas de seguridad basadas en trabajos científicos recientes. Los temas incluyen seguridad del sistema operativo (SO), características, gestión del flujo de información, seguridad del idioma, protocolos de red, seguridad de hardware y seguridad de aplicaciones web.

Lección 1: "Introducción: modelos de amenaza" Parte 1 / Parte 2 / Parte 3
Lección 2: "Control de ataques de hackers" Parte 1 / Parte 2 / Parte 3
Lección 3: “Desbordamientos del búfer: exploits y protección” Parte 1 / Parte 2 / Parte 3
Lección 4: “Separación de privilegios” Parte 1 / Parte 2 / Parte 3
Lección 5: “¿De dónde vienen los sistemas de seguridad?” Parte 1 / Parte 2
Lección 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Lección 7: “Sandbox de cliente nativo” Parte 1 / Parte 2 / Parte 3
Lección 8: "Modelo de seguridad de red" Parte 1 / Parte 2 / Parte 3
Lección 9: "Seguridad de aplicaciones web" Parte 1 / Parte 2 / Parte 3
Lección 10: “Ejecución simbólica” Parte 1 / Parte 2 / Parte 3
Lección 11: "Ur / Lenguaje de programación web" Parte 1 / Parte 2 / Parte 3
Lección 12: Seguridad de red Parte 1 / Parte 2 / Parte 3
Lección 13: "Protocolos de red" Parte 1 / Parte 2 / Parte 3
Lección 14: "SSL y HTTPS" Parte 1 / Parte 2 / Parte 3
Lección 15: "Software médico" Parte 1 / Parte 2 / Parte 3
Lección 16: "Ataques de canal lateral" Parte 1 / Parte 2 / Parte 3
Lección 17: "Autenticación de usuario" Parte 1 / Parte 2 / Parte 3

Entonces comencemos. Con el regreso de ustedes, espero que las vacaciones para todos hayan sido un éxito. Hoy hablaremos sobre la autenticación de usuarios. Entonces, ¿el tema de la conferencia es descubrir cómo los usuarios pueden demostrar su identidad al programa? En particular, el artículo, destinado a la lección de hoy, toca los fundamentos de la existencia de una comunidad de seguridad. ¿Hay algo mejor para la autenticación que las contraseñas?



Al más alto nivel, parece que las contraseñas son una idea terrible, porque tienen una entropía muy baja y es fácil para los atacantes resolverlas. Las preguntas secretas que utilizamos para recuperar contraseñas olvidadas tienen incluso menos entropía que las contraseñas mismas, y esto también parece ser un problema.

Y lo que es peor, los usuarios generalmente usarán la misma contraseña en muchos sitios diferentes. Esto significa que una vulnerabilidad en una contraseña fácil de adivinar pone en peligro el trabajo del usuario con muchos sitios.

Me gustó la siguiente cita de un artículo de la conferencia de hoy: "el dominio continuo de las contraseñas entre todos los demás métodos de autenticación de usuarios es un obstáculo importante para la investigación de seguridad". Por lo tanto, la comunidad de investigación de seguridad quiere tener una alternativa mejor que las contraseñas. Sin embargo, no está claro si realmente existe un esquema de autenticación que pueda reemplazar completamente las contraseñas, a la vez que sea más conveniente, más amplio y más seguro.

Hoy consideraremos tres cuestiones. Primero, veremos cómo funcionan las contraseñas existentes. Después de eso, hablaremos sobre las propiedades de contraseña global deseadas para cualquier esquema de autenticación. Finalmente, observamos lo que analiza el artículo de la conferencia sobre métricas o características de autenticación y cómo se comparan algunos otros esquemas de autenticación en términos de eficiencia con las contraseñas.



Entonces, ¿qué es una contraseña? La contraseña es un secreto compartido para el usuario y el servidor. Por lo tanto, una implementación primitiva de un esquema de contraseña debería tener básicamente una tabla del lado del servidor que asigne los nombres de usuario a sus contraseñas.

Esta es la forma más fácil de imaginar la implementación de uno de los esquemas de autenticación: el usuario ingresa su nombre y contraseña, el servidor los busca en esta tabla, compara la contraseña con el nombre y, si todo coincide, el usuario se autentica. Claramente, el problema es que si un atacante irrumpe en el servidor, puede simplemente mirar esta tabla y hacerse cargo de todas las contraseñas. Entonces esto es claramente algo malo.

Quizás la solución a este problema es almacenar la tabla en el servidor, que se ve así: el nombre de usuario no corresponde a la contraseña en sí, sino a su hash. En este caso, el usuario ingresa la contraseña en texto plano, el servidor verifica su código hash y lo compara con el valor de la tabla. La ventaja de este esquema es que estas funciones hash están diseñadas de tal manera que el hash es difícil de invertir en una contraseña. Si se pierde esta tabla, hay una fuga de datos, o el atacante pirateó el servidor y se apoderó de él, verá cadenas de caracteres alfanuméricos aleatorios en lugar de contraseñas de texto, y le será difícil restaurar su imagen original.

Al menos en teoría, usar hashes es algo bastante bueno. Pero ahora en la práctica, los atacantes no tendrán que usar un ataque de fuerza bruta para determinar la imagen inversa del valor hash.



Los atacantes realmente pueden aprovechar el hecho de que en la práctica las contraseñas tienen una distribución desigual. Y por la distribución desigual, quiero decir ... digamos que sabemos que todas las contraseñas tienen hasta 20 caracteres de longitud. En la práctica, los usuarios no usan todo este rango, prefieren contraseñas como 123, todd o algo similar. Sin embargo, los estudios empíricos han demostrado cómo funcionan estas contraseñas, y se descubrió que aproximadamente el 20% de los usuarios usan las 5000 contraseñas más populares. En otras palabras, esto significa que si un atacante tiene una base de datos de estas 5,000 contraseñas, puede descifrarlas fácilmente y luego, cuando vea la tabla de contraseñas robadas, simplemente haga coincidir los hashes. Entonces, empíricamente, un hacker podrá recuperar aproximadamente el 20% de las contraseñas que están en la tabla del servidor.

Los expertos de Yahoo descubrieron que las contraseñas contienen de 10 a 20 bits de entropía, 10-20 bits de aleatoriedad. De hecho, esto no es tanto. Teniendo en cuenta la complejidad de crear una función hash, las máquinas modernas calculan millones de tales hash cada segundo. Por lo tanto, una función hash debe ser fácilmente computable en diseño para que las computadoras puedan fácilmente cambiar las contraseñas. Sin embargo, la combinación de este hecho con una aleatoriedad insuficiente de las contraseñas significa que, en principio, este esquema no es tan seguro como parece.

Hay una cosa con la que puedes intentar complicar la vida de un hacker: esta es una función compleja de generar una clave. En este caso, quiero decir que el hash de contraseña se utiliza como datos de origen, en función del cual el servidor genera una clave que se almacena en el servidor.



Lo bueno de estas funciones de generación de claves es que tienen una complejidad personalizable, es decir, puede girar un cierto mando y hacer que esta función funcione más lento o más rápido dependiendo de cuánto desee ahorrar en el rendimiento del proceso.

Suponga que desea generar una clave. Un ejemplo es el estándar de generación de claves PBKDF2 o, posiblemente, BCrypt, puede obtener más información sobre ellos en Internet. Imaginemos que una de estas funciones de generación de claves requiere un segundo entero, no unos pocos milisegundos, para calcular. De hecho, esto hará que el trabajo del atacante sea mucho más difícil, porque el intento de generar valores para las 5000 contraseñas "superiores" llevará mucho más tiempo.

A nivel interno, estas funciones de generación de claves a menudo funcionan llamando repetidamente a un hash, accediendo a él muchas veces, por lo que todo es bastante simple. Pero, ¿el uso del lento proceso de generación de claves resuelve el problema de seguridad que enfrentamos? La respuesta es no, porque uno de los problemas es que el adversario puede construir algo llamado tablas del arco iris o "tablas del arco iris". Una tabla de arcoiris es simplemente un mapa de cómo una contraseña coincide con un valor hash. Por lo tanto, incluso si el sistema usa una de estas costosas funciones de generación de claves, un atacante puede calcular una de estas tablas una vez. Esto puede ser un poco complicado, porque el procesamiento de cada función de generación de claves es bastante lento, pero un atacante puede crear esta tabla una vez y luego usarla para descifrar todos los sistemas posteriores basados ​​en los mismos algoritmos de función de generación de claves. Así es como funcionan estas mesas arcoiris.

Repito una vez más: para maximizar los beneficios económicos de crear la tabla Rainbow, un atacante puede aprovechar la distribución desigual de las contraseñas, de las que hablé antes. Por lo tanto, un atacante puede crear dicha tabla solo para un pequeño conjunto de todas las contraseñas posibles.

Estudiante: ¿ probablemente "salazón" lo hace mucho más difícil?

Profesor: sí, sí, exactamente. Iremos a la "salazón" en un par de segundos. En general, si no usa sal, las tablas de arco iris permiten que un atacante, con cierto esfuerzo en modo fuera de línea, calcule esta tabla y luego se beneficie de la capacidad de calcular contraseñas básicas en función del trabajo realizado.

Lo siguiente que puede pensar para mejorar la situación es la salazón. Como funciona El principio básico es introducir algo de aleatoriedad adicional en el método de generación de contraseña. Usted toma esta función hash, coloca la "sal" y luego la contraseña, y todo esto se almacena en una tabla en el servidor.



¿Qué es la sal? Esta es solo una cadena larga que representa la primera parte de esta función hash. Entonces, ¿por qué es mejor usar este esquema? Tenga en cuenta que la "sal" en realidad se almacena en texto claro en el lado del servidor. Puede pensar: Bueno, si esta "sal" se almacena en texto claro en el lado del servidor y un atacante puede robar una tabla de nombres de usuario para contraseñas, entonces ¿por qué no puede robar también esta "sal"? ¿Cuál es el uso de tal solución?

Estudiante: porque si elige la contraseña más común, no puede usarla una sola vez y encontrar un nuevo usuario.
Profesor: absolutamente cierto. Básicamente, lo que hace la sal es evitar que el atacante cree una única tabla de arco iris que pueda usarse contra todos los hashes. En principio, puede considerar la "sal" como una forma de hacer que incluso las mismas contraseñas sean únicas. En la práctica, muchos sistemas utilizan el concepto de "salazón".

De hecho, la "sal" permite agregar tantos bits como sea posible a esta pseudocontraseña, ya que cuantos más bits, mejor. Lo que hay que hacer es tener en cuenta que cada vez que el usuario cambia su contraseña, la "sal" también debe cambiarse. Porque uno de los motivos de esta decisión es la pereza de los usuarios que desean utilizar la misma contraseña varias veces. Cambiar la "sal" asegurará que lo que está almacenado en la base de datos de contraseñas realmente diferirá incluso si una contraseña se reemplaza con exactamente la misma contraseña.

Audiencia: ¿por qué se llama "sal"?

Profesor: Esta es una buena pregunta, y no puedo responderla con seguridad. Sin embargo, estoy seguro de que hay alguna justificación para esto. ¿Por qué las cookies se llaman cookies? Probablemente Internet sepa por qué, pero no lo sé.

Estudiante: ¿ quizás porque “sal” agrega un poco de “sabor” al hachís?

Profesor: bueno, me alegra que estemos filmando esto porque claramente tenemos la oportunidad de obtener un premio de cine. Estoy seguro de que hay algún tipo de respuesta en Internet, por lo que la buscaré más adelante.
Entonces, los enfoques anteriores son bastante simples. Supuse que el usuario de alguna manera envía la contraseña al servidor, pero no especifiqué cómo sucede. Entonces, ¿cómo pasamos estas contraseñas?

En primer lugar, simplemente puede enviar la contraseña a través de la red en texto claro. Esto es malo porque puede haber un intruso en la red que supervisa el tráfico que envía. Él simplemente puede asignar una contraseña y hacerse pasar por usted.

Por lo tanto, siempre comenzamos con un hombre de paja, antes de mostrarle a los otros hombres de paja, que, por supuesto, también tienen fallas fatales. Entonces, lo primero que puede pensar es enviar la contraseña en texto claro. Desde el punto de vista de la seguridad, es mucho mejor enviar una contraseña a través de una conexión cifrada, por lo que utilizamos la criptografía. Es posible que tengamos algún tipo de clave secreta utilizada para convertir la contraseña antes de enviarla a través de la red. Entonces, al más alto nivel, parece que el cifrado siempre hace las cosas mejor, como una marca comercial que garantiza la calidad del producto.

Pero el problema es que si no piensa cuidadosamente sobre cómo usar el cifrado y el hash, no puede aprovechar los beneficios de seguridad con los que cuenta. Por ejemplo, si hay alguien que se sienta entre usted: el usuario y el servidor, este notorio atacante, el "hombre en el medio" que realmente monitorea su tráfico, mientras finge ser un servidor.

Si envía datos cifrados sin autenticar el otro lado, puede encontrarse con un problema. Porque el cliente simplemente selecciona una clave aleatoria y la envía a un destino en el otro lado, que puede o no ser el servidor.

De hecho, está enviando algo a una persona que luego tendrá la oportunidad de tomar posesión de todos sus secretos.

Dado esto, la gente puede pensar que es mucho mejor enviar no la contraseña en sí, sino su hash. De hecho, esto por sí solo no le da nada, porque si envía una contraseña o un hash de contraseña, este hash de contraseña tiene la misma fuerza semántica que la contraseña original, y no ayudará si no ha autenticado el servidor.

Entonces, el punto principal es que solo agregar cifrado o simplemente agregar hashing no necesariamente le brinda ningún beneficio de seguridad adicional. Si el cliente no puede autenticarse a quién le envía la contraseña, entonces el cliente puede revelar la contraseña por error a alguien que no tiene la intención de revelarla.

Por lo tanto, quizás una mejor idea que las dos anteriores es utilizar el llamado protocolo desafío / respuesta, o protocolo desafío / respuesta. Aquí hay un ejemplo de un protocolo de llamada / respuesta muy simple. Aquí tenemos un cliente, y aquí tenemos un servidor. El cliente le dice al servidor: "Hola, soy Alice", después de lo cual el servidor responde con una llamada C. Luego el cliente responderá con un hash de esta llamada enviada por el servidor, combinándola con una contraseña.



El servidor conoce la respuesta, por lo que en este momento puede aceptar esta secuencia: la respuesta del cliente. El servidor también conoce el desafío que envió, y presumiblemente conoce la contraseña, por lo que el servidor puede calcular el valor del hash recibido y ver que realmente coincide con el enviado por el usuario.

Una característica positiva de este protocolo, si ignoramos la existencia de un "hombre en el medio" por un segundo, es que el servidor estará seguro de que el usuario es realmente Alice, porque solo Alice sabrá esta contraseña. Al mismo tiempo, si Alice envía esto no al servidor, sino a la persona que pretendió ser el servidor, entonces él no sabrá la contraseña. Debido a que un atacante puede usar C, pero aún no conoce la contraseña, y para descubrir la contraseña, necesita invertir esta función hash nuevamente. ¿Tienes alguna pregunta?

Estudiante: ¿ puede un cliente en lugar de enviar una contraseña a un servidor y recibir una llamada de servidor hash simplemente enviar una contraseña hash al servidor?

Profesor: es decir, ¿pregunta por qué el cliente simplemente no envía la contraseña cifrada al servidor? Hay 2 razones para esto. Discutiremos uno más tarde, se llama protección contra el martilleo y fue creado para defenderse contra clientes "malos", preguntando constantemente: "¿es esta una contraseña, o es una contraseña, tal vez es una contraseña?" Este mecanismo de autenticación simplifica el proceso tanto para el servidor como para el cliente, pero esencialmente puede crear un hash en el lado del cliente, usando JavaScript o algo así. Pero la idea básica es que de alguna manera debe garantizar la máxima complejidad de autenticación para evitar que el atacante adivine rápidamente la contraseña. ¿Alguna otra pregunta?



Estudiante: Solo quería señalar que incluso si el cliente realiza el hashing, en el caso de que alguien tome el control de la tabla del servidor y la use para el hash, podrá ingresar a la red.

Profesor: absolutamente cierto. Sí, se vuelve un poco peligroso dependiendo de quién puede tomar posesión de esta llamada C. Porque si el cliente y el servidor pueden elegir los valores de esta C, esto complica la capacidad del cliente para organizar tales ataques. Uno de los problemas con el uso de este protocolo es que el cliente no puede aleatorizar este valor de HCC. Uno puede imaginar que puede hacer que este protocolo sea más complicado para la inversión del servidor si el cliente puede seleccionar alguna llamada C en la parte de HCC, pero en este caso habrá una yuxtaposición de llamadas de cliente y servidor.
Si no hay más preguntas, asumiremos que hemos terminado la discusión sobre los mecanismos de transferencia de contraseña del cliente al servidor. , , brute-force, -, .

, , , HCC. , «». « ».

, , , , « ». «» , « » .

Antihammer – , , . , , brute-force , . , Antihammer – , , : « ».



-, . , 10 , : « 10 , ». . «» , TPN . ? – , , , .
, , , - . , , - , , . – . , , .

, — , , — . , , . , . , , .

, , , Dictionary attack, « ». , , Microsoft Telepathwords. . , , , Telepathwords , . , , , , .



«», , , , , «».



«» , . Telepathwords? , , . , .



, . , , . , .

, Telepathwords , , , , , . .
, — , , , .

: , , IP- , Antihammer .

: , . Antihammer IP-, , . , Antihammer , – . , Antihammer , , , , , , .

, . , . , .

: Antihammer? , , ? , , SRP Zero Knowledge Protocol, ZKP, …

: , ?

: ?

: , . . , , . , , , ZKP, .

27:20

Curso MIT "Seguridad de sistemas informáticos". 17: « », 2


.

Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendándolo a sus amigos, un descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps hasta diciembre de forma gratuita al pagar por un período de seis meses, puede ordenar aquí .

Dell R730xd 2 veces más barato? Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los EE. UU. Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?