¿Cómo puedo evitar que los usuarios usen contraseñas incorrectas en mi aplicación web?

Educación, amenazas y herramientas.

La primera mitigación de problemas de seguridad es enlistar usuarios. De todos modos, no puede obtener una buena seguridad sin su conocimiento, por lo que puede pedir su ayuda. Publicar pautas sobre cómo se debe elegir una contraseña.

Para reforzar el punto anterior, presiona un poco (solo un poquito). Habla la palabra fatídica: "responsable". Los seres humanos son humanos, algunos necesitarán el incentivo adicional; En particular, tener cuidado de explícitamente deletrear quiénes serán los ataques de falla, enfatizará la seriedad del problema. La gente no creerá en la importancia de los problemas de seguridad si usted, como encargado del servidor, no hace su tarea. Estas amenazas pequeñas y poco ocultas empujarán a los usuarios a la zona ligeramente incómoda donde están alerta . ¡No te excedas! Quiere usuarios que cumplan , no usuarios que luchen contra su sistema .

En ese punto, ayuda a los usuarios. El hecho básico de la generación de contraseñas es que los humanos no son buenos para la aleatoriedad . Pero la aleatoriedad es lo que se necesita para una contraseña. Dado que se trata de una aplicación web, tiene un servidor web de confianza: "de confianza" en el sentido de que la contraseña es para garantizar la seguridad de ese servidor, por lo que el servidor mismo no puede ser un enemigo ( no tiene sentido). Por lo tanto, use ese servidor: incluya un generador de contraseñas . Algo que producirá buenas contraseñas, accesibles con un solo clic.

Las dos facetas de la generación de contraseñas son que la contraseña no debe ser adivinable, pero debe ser memorizada de todas formas. Al dar las reglas para la generación de contraseñas, asume que la mnemotecnia por la cual el usuario las recuerde la contraseña coincidirá exactamente con el proceso por el cual se creó la contraseña creada . Esta es una restricción artificial. Considere el famoso generador de contraseñas de XKCD : el generador no trata de elegir cuatro palabras que "tengan sentido" juntas; en su lugar, se trata de seleccionar cuatro palabras al azar y luego, solo entonces, encontrar un "significado" para ello (como el dispositivo de almacenamiento de electricidad que medita en mamíferos ungulados). Esto resalta cómo se generan las contraseñas seguras: usa la aleatoriedad , luego entrena al cerebro para enfrentar el resultado.

Un esquema de generación de contraseñas que me gusta mucho va así: genera dos letras, luego dos dígitos, luego dos letras, luego dos dígitos. Para complacer a las interfaces de aplicaciones inflexibles, haga que las dos primeras letras sean minúsculas y las otras dos mayúsculas. La entropía de este proceso de generación es 10 ⁴ * 26 ⁴ , es decir, un poco por encima de 2 ³² . 32 bits de entropía no son malos: tomará un promedio de más de dos mil millones de intentos para romper una contraseña de ese tipo. Esto es suficiente para la seguridad en línea (a su servidor le tomaría mucho tiempo "probar" tantas contraseñas). Por otro lado, encuentro que estas contraseñas aleatorias son fáciles de recordar . Intentalo ! Ya recuerdas los números de teléfono, que son solo numéricos; Las letras son grandes "anclas" para la mente y hacen que la memorización sea más fácil. Aquí hay cinco contraseñas de ese tipo, recién generadas (no las elegí):

sf57HD04
sd82PI16
ny21BF75
xv53AQ36
jz91EQ92

Por cada uno de ellos, creo que ya estás encontrando una forma sencilla de "reconstruir" en tu cerebro, como si lo hubieras creado de una manera ingeniosa. Pero como se han generado con aleatoriedad real, su entropía está intacta.

Hay algunas maneras en las que puedo pensar.

Requerir ciertas combinaciones de caracteres

Esta es una técnica de uso común. Exigir a los usuarios que ingresen una cierta combinación de caracteres, como una combinación de palabras en mayúsculas, palabras en mayúsculas, números y símbolos. Imponer una longitud mínima de contraseña. Sin embargo, no sea demasiado restrictivo, ya que podría forzar a los usuarios a combinar combinaciones de una manera insegura.

Password1234 no es más seguro que password .

Esta técnica también podría restringir frases de contraseña fuertes. Consulte: XKCD # 936: Contraseña compleja corta o larga ¿frase de contraseña del diccionario?

Denegar contraseñas comunes mediante una lista negra

Mantenga una lista negra de contraseñas comúnmente crackeadas y no permita que los usuarios se registren usándolas. Esto podría ser una cantidad considerable de trabajo para mantener.

También agregaría que las contraseñas débiles se pueden mitigar significativamente si hay buenas restricciones en los intentos de inicio de sesión. No lo protegerá si su archivo hash se pierde y no se detecta, pero en ese momento es más un problema de administrador. La mayor preocupación por el tema de mayor seguridad sería que las contraseñas podrían reutilizarse desde otros sitios que podrían verse comprometidas. Hacer un nombre de usuario que no sea directamente compatible con un usuario es una forma decente de evitar esto. Incluso si sé que Bob Worker usa BobW0rker12345 para su contraseña de Facebook, si no conozco las credenciales de inicio de sesión de Bob Worker, entonces tener acceso a su contraseña de Facebook no me ayuda.

Los requisitos de complejidad de la contraseña también pueden ayudar a garantizar que no se pueda adivinar fácilmente, pero también vienen con una variedad de advertencias estúpidas para el usuario, como personas que escriben contraseñas o se frustran directamente con su sistema y tratan de luchar directamente su sistema porque está dificultando su vida útil, por lo que siempre debe ponderar el riesgo frente a la recompensa por los requisitos de complejidad de la contraseña. A veces es realmente necesario y, de ser así, pasa al tercer y más crítico punto de la educación del usuario.

Sus usuarios deben comprender por qué es necesario el nivel de seguridad y estar dispuestos a participar. En última instancia, sus usuarios colectivamente son mucho más creativos que usted y HACERÁN cosas que no esperaba que comprometan la seguridad a menos que comprendan la importancia y se inviertan en ella.

La respuesta debe depender en gran medida del propósito de la contraseña.

¿Es algo así como un foro? Entonces, no moleste a los usuarios forzándolos a reemplazar la o en su contraseña predeterminada por un 0. Eso es todo lo que va a hacer antes de simplemente abandonar su sitio. No dude en notificarles que su contraseña es mala y que no asumirá ninguna responsabilidad, pero no los obligue a usar la única contraseña compleja que puedan recordar: en su cuenta de PayPal ...

¿Es algo así como una tienda? Luego, advierta a los usuarios sobre la debilidad de su contraseña y tal vez pídales que la confirmen dos veces, incluido el mensaje "Soy consciente de que es más probable que mi contraseña esté descifrada que otras y no acudiré a usted llorando por ello". cuando eso suceda "declaración. Pero no los obligue a usar una contraseña que no puedan recordar: argumentaría que un administrador de contraseñas debería ser estándar, pero no lo es, y sus usuarios no deberían considerar la función de restablecimiento de contraseña como la forma predeterminada de iniciar sesión. in. Considere ofrecer autenticación de dos factores o OpenID en su lugar.

¿Es realmente la interfaz web para lanzar un arma nuclear o activar los sistemas de soporte de vida ISS? En ese caso, el uso de una mera autenticación de contraseña es un defecto grave en sí mismo, aunque no es tan malo como conectar realmente estas cosas a Internet.

Cálculo de entropía.

Una palabra del diccionario, nombre propio u otro miembro del idioma inglés moderno tiene, en promedio, alrededor de 1.5 bits de entropía por letra. Para esto, puede agregar un bit por cada letra mayúscula, un bit por cada sustitución "leet" (0 para o, 1 para i, 2 para q, 3 para e, 4 o @ para a, etc.), 3 bits para cada dígito numérico en un prefijo o sufijo que no está en orden secuencial, y 4 bits por cada signo de puntuación que no se utiliza como sustitución.

Para calcular la entropía automáticamente en función de una contraseña ingresada, eliminaría todos los números / símbolos iniciales y finales, dividiría en mayúsculas y ejecutaría lo que queda a través de un corrector ortográfico para obtener la (s) palabra (s) real (es).

Tome la suma de todos los bits de entropía y aumente 2 a esa potencia. Esa es la cantidad de adivinanzas de fuerza bruta que se necesitarían para probar todas las posibilidades utilizando un cracker basado en diccionario. La rapidez con la que podría suceder depende de la rapidez con la que su puerta de entrada pueda procesar los intentos de inicio de sesión; Recomiendo la verificación de contraseña basada en un hash lento (bcrypt) del lado del servidor junto con un número máximo de intentos de inicio de sesión, además del mecanismo que utilice para asegurar la transmisión de la contraseña de cliente a servidor.

De todos modos, una vez que tenga un puntaje y sepa lo que significa en términos de la duración de un ataque (honestamente, si ve que faltan 3 horas de intentos repetidos de inicio de sesión fallidos, debe haber timbres de alarma), puede establecer umbrales para "débil", "normal", "fuerte", etc., y no aceptar una contraseña "débil". Comprenda que, debido a la ley de Moore, la contraseña segura de hoy es la contraseña débil de mañana, y lo que requiere un cracker basado en GPU podría requerir una red de bots o una agencia de inteligencia.

• La protección de contraseña en sí misma es intrínsecamente insegura

• La pregunta no se puede responder fácilmente sin un contexto adicional. El grado de seguridad de una contraseña depende del valor del recurso que protege. Por lo tanto, hasta qué punto una aplicación debe hacer algo respecto de la fortaleza de una contraseña depende de lo que protege (aunque hay un problema de personas que usan la misma contraseña en varios sitios; consulte el siguiente punto).

• La educación y conciencia del usuario es crítica. La falta de educación y conciencia creará resentimiento entre sus usuarios si los obliga a usar contraseñas que considere muy sólidas y que consideren difíciles de crear o recordar. Del mismo modo, un desajuste entre la fuerza impuesta y el valor percibido de lo que se está protegiendo causará resentimiento.

• Considere la amenaza y cómo se puede realizar. Los ataques de fuerza bruta rara vez ocurren a través de una interfaz de aplicación. La mayoría de las veces, se aplican a un conjunto de contraseñas que han sido robadas del repositorio de back-end de la aplicación. No tiene sentido forzar a los usuarios a ingresar contraseñas seguras si la forma en que almacena y administra esas contraseñas significa que alguien puede obtenerlas. Con el tiempo, la CPU y la memoria suficientes y los algoritmos de cifrado deficientes, la seguridad de la contraseña se vuelve irrelevante.

Aparte de eso, creo que es razonable reducir su exposición mediante la aplicación de contraseñas seguras. Yo no iría por la borda. Imponga la longitud mínima de la contraseña, la combinación de mayúsculas / minúsculas y la inclusión del número y los caracteres de puntuación, pero acepte que los usuarios encuentren / hagan cosas que aún comprometan sus intentos. Reconozca que las contraseñas son intrínsecamente inseguras cuando se usan como el único método de autenticación y ponderan eso contra el valor de lo que se está protegiendo. Si el riesgo sigue siendo demasiado alto, considere mecanismos adicionales, como la autenticación de dos factores.

Esto no se mide en absolutos. No existe una solución única para todas las soluciones y la seguridad de la contraseña no es la única pieza del rompecabezas que debe considerar. Observe cómo almacena y administra las contraseñas, considere de dónde es probable que se produzca un ataque, cómo se le alertará sobre tal ataque, cómo conseguir que sus usuarios adopten buenas prácticas, cómo equilibrar el valor y los inconvenientes de cualquier medida de seguridad, etc. . y recuerde que esto no es un proceso de hacer y olvidar. Esto es algo que debe revisarse y actualizarse periódicamente a medida que la tecnología, las técnicas y el comportamiento cambian.

Una mejor pregunta puede ser: ¿Por qué mi aplicación web requiere contraseñas en primer lugar?

No tengo contraseñas para ninguna de mis cuentas de StackExchange.

Dependiendo de la aplicación, vincularlo con otro servicio de autenticación, o generar una contraseña pseudoaleatoria de forma predeterminada, podría ser el mejor enfoque.

Si generas una contraseña pseudoaleatoria, es posible que desees que sea lo suficientemente aleatoria pero que sea fácil de recordar.

Hay una serie de herramientas que generan contraseñas con consonantes intercambiadas con vocales , posiblemente intercambiadas con un par de números; tales contraseñas son intrínsecamente sólidas para las aplicaciones web (ya que no se puede forzar la aplicación bruta de una aplicación web sin ser detectadas), pero son fáciles de recordar, ya que no parecen totalmente aleatorias, sino que se parecen a una palabra extraña o nombre.

Un ejemplo de una buena herramienta que genera contraseñas fáciles de recordar, legibles y pronunciables es una herramienta de consola llamada pwgen.

enlace
enlace