¿Se requiere complejidad de contraseña en absoluto?

1

Para un sitio web, estoy usando lo que espero que sea el esquema de almacenamiento de contraseña más seguro que puedo encontrar, que se reduce a tener una contraseña de sal y hash almacenada en una base de datos de contactos: -

        Byte[] lPassword;
        var lRNG = new System.Security.Cryptography.RNGCryptoServiceProvider();
        var lSalt = new Byte[16];
        lRNG.GetBytes(lSalt);
        using (var lPDBGen = new Rfc2898DeriveBytes(Password, Salt, 1000)) {
            lPassword = lPDBGen.GetBytes(16);
        }
        ... Save lPassword and lSalt to the database ...

Si un atacante obtiene acceso a esta información, esencialmente tiene acceso a los datos protegidos (no puedo pagar un servidor de contraseña seguro por separado).

Por lo tanto, el uso de este esquema ¿tiene algún propósito en absoluto la necesidad de cualquier forma de complejidad en la elección de la contraseña del usuario, hasta e incluyendo una contraseña vacía?

    
pregunta Richard Petheram 07.10.2013 - 11:43
fuente

3 respuestas

4

Desafortunadamente, uno no puede simplemente preguntar por la complejidad de la contraseña.

Lo que realmente desea, para la seguridad de la contraseña, es que la contraseña tenga una alta entropía ; Pero la entropía no es una propiedad de la contraseña. En cambio, la entropía califica la forma en que se elige la contraseña. "Alta entropía" significa "la contraseña podría haber sido muchos otros valores".

Los "verificadores de contraseñas" habituales no pueden entrar en el cerebro del usuario humano, por lo que no pueden realmente adivinar cómo el usuario elige sus contraseñas. Del mismo modo, las "reglas de complejidad de contraseñas" no pueden garantizar contraseñas seguras; solo intentan expulsar al usuario de su zona de confort, para evitar algunos métodos clásicos de generación de contraseñas débiles. Pero en la práctica, no funcionan. La aleatoriedad es difícil para los cerebros humanos. Los humanos no pueden tomar decisiones realmente aleatorias en la privacidad de sus mentes; en cambio, hacen elecciones ingeniosas . Además, no les gusta ser obligados a tomar decisiones pseudoaleatorias. Cuando las reglas de complejidad de las contraseñas están vigentes, el resultado habitual es que los usuarios crean soluciones ingeniosas, lo que da como resultado contraseñas que cumplen con las reglas, pero no son aleatorias; por lo tanto, contraseñas débiles.

Un caso típico es cuando las reglas de complejidad exigen que una contraseña tenga al menos un dígito y al menos un signo de puntuación: en la práctica, los usuarios reaccionan agregando sistemáticamente "1!" a cualquier contraseña que les hubiera gustado. Así que las reglas hacen que la contraseña sea más larga pero no más fuerte . De hecho, incluso hacen las contraseñas más débiles porque ese tipo de sufijo sistemático todavía contará como dos caracteres con respecto a la longitud de la contraseña. Si su sistema impone una longitud de contraseña mínima de ocho caracteres, entonces las personas deberán elegir contraseñas de ocho caracteres; pero si agregan un sufijo sistemático de dos caracteres (y los atacantes lo saben, porque el atacante es un tipo inteligente que sabe cómo piensan los usuarios típicos), entonces pueden deshacerse de la regla de longitud de la contraseña con solo 6 caracteres aleatorios reales. En tal caso, las reglas de complejidad de las contraseñas son contraproducentes: inducen comportamientos del usuario que son perjudiciales para la seguridad, es decir, contraseñas más débiles.

La única "regla de complejidad" que es sensible es una longitud mínima (normalmente 8 caracteres) porque mientras que una contraseña larga no es necesariamente segura, una contraseña muy corta siempre es débil, porque simplemente no hay suficientes contraseñas de 6 caracteres posibles .

Todo lo anterior apunta a explicar que las contraseñas elegidas por el usuario serán débiles, para una proporción sustancial de los usuarios. Esto es malo, pero el punto es que las "reglas de complejidad de la contraseña" no mejoran realmente la situación.

Lo que se puede hacer es lo siguiente:

  • Utilice una función de hashing de contraseña . Eso es lo que haces con PBKDF2 ( Rfc2898DeriveBytes implementa PBKDF2). Las sales y las iteraciones ayudan a hacer frente a las contraseñas de baja entropía, hasta cierto punto. Sin embargo, es posible que desee aumentar el número de iteraciones: es probable que su servidor pueda soportar más de 1000 iteraciones, y cuanto más alto, mejor.

  • Intenta que la pregunta sea nula. Se debe usar el hash de contraseña porque a veces sucede que los atacantes obtienen una copia de (parte de) la base de datos del servidor, con todas las contraseñas de hash; La inyección de SQL, en particular, a menudo resulta en tal resultado. Sin embargo, es mucho mejor si evitas eso. La aplicación de contraseñas es una segunda línea de defensa necesaria, pero eso no significa que la primera línea de defensa no sea importante.

  • Para en línea ataques de diccionario, donde el atacante habla con su servidor para cada intento de contraseña, aplique elementos disuasorios: si demasiadas solicitudes de inicio de sesión provienen de una sola IP en un tiempo demasiado corto, temporalmente prohibir esa propiedad intelectual.

  • Eduque a sus usuarios . Una buena manera de hacer que los usuarios elijan contraseñas seguras es proporcionar un generador de contraseñas . Es importante que el generador sea opcional , de lo contrario los usuarios lo sentirán como una restricción y se negarán a usarlo. Un generador puede confiar en la aleatoriedad real (es decir, una computadora, tiene RNGCryptoServiceProvider ) y, por lo tanto, cumplir con un objetivo de entropía razonable. Un método de generación de contraseña favorito es un patrón "aa00aa00" (dos letras, dos dígitos, dos letras y luego dos dígitos). Dichas contraseñas son relativamente fáciles de recordar y escribir, y aún así brindan un poco más de 32 bits de entropía, lo cual es suficiente siempre que use PBKDF2 con un número de iteraciones suficientemente alto.

respondido por el Tom Leek 07.10.2013 - 15:50
fuente
4

No importa qué tan fuerte sea el algoritmo de hash de tu contraseña (bueno, sí importa. Pero no mucho) cuando la contraseña es estúpidamente débil.

Las contraseñas comunes como password123 o ilovehowmileycyrustwerks caerán rápidamente a ataques de diccionario independientemente.

    
respondido por el Ayrx 07.10.2013 - 11:47
fuente
0

La respuesta de Tom con respecto a "educar a sus usuarios" es todo lo que la comunidad de seguridad ha estado diciendo durante mucho tiempo. Sin embargo, no ha funcionado tan bien en la práctica. Las razones son complejas, pero se reducen a dos conceptos centrales: una cadena es tan fuerte como su eslabón más débil, y la vieja broma de que el 50% de sus usuarios están por debajo del promedio.

Primero, la analogía de la cadena. A un atacante usualmente no le importa con qué ID ingresan. Si se les da 10,000 para crackear, tan pronto como tengan una sola contraseña débil, estarán dentro. Y aplicando eso a los usuarios por debajo del promedio, eso significa que si solo uno de sus usuarios es descuidado, descuidado o tonto, el atacante está dentro. La capacitación de personas ayuda a reducir la exposición, pero debido a la analogía de la cadena no puede detener los ataques. No se puede confiar en nunca para detener todos los ataques.

Aquí es donde necesita hacer una copia de seguridad de sus sistemas con la estrategia de seguridad clásica de defensa en profundidad. No puedes simplemente lanzar una casilla de contraseña delante de un sitio y luego dejar todo lo demás como estaba, porque deberías aceptar que uno o más de tus usuarios son descuidados o no confiables.

Desde el punto de vista de un ataque montado por un usuario "confiable", muchos sistemas tienen menos pruebas de seguridad y tienen varios defectos que permiten una escalada de privilegios. Dirígete a los primeros, por supuesto. Pero también necesitas asegurar adecuadamente tus sistemas de back-end. Es caro, pero si alguna vez has visto a un examinador de bolígrafos abrirse camino a través de un sistema inseguro, entenderás exactamente por qué es necesario cerrar todas las puertas.

Después de parchear todos sus sistemas, todavía tiene la inseguridad del usuario "confiable" y lo que legítimamente le permite hacer. ¿Puede transferir fácilmente todo su saldo a un banco de las Islas Caimán a las 3AM desde una dirección IP en Estonia? Tal vez no sea una buena idea. Tal vez agregue un paso de autenticación de dos factores para transacciones fuera de lo normal de tamaño moderado; ¿Algo fuera de banda como un mensaje SMS o correo electrónico? ¿Quizás necesita que un funcionario se ponga en contacto con él antes de aprobar la transferencia de una gran cantidad?

    
respondido por el John Deters 10.10.2013 - 00:16
fuente

Lea otras preguntas en las etiquetas