¿Están las contraseñas comunes en un riesgo particular?

Algunos especialistas en UX dicen que no es una buena idea rechazar una contraseña. Uno de los argumentos es el que usted proporciona: "pero si los prohíbe, los usuarios usarán otras contraseñas débiles", o agregarán caracteres aleatorios como 1234 - > 12340, que es estúpido, sin sentido y luego obligará al usuario a pasar por el proceso de "perder mi contraseña" porque no puede recordar qué caracteres agregó.

Tienes dos opciones. Me gustan los dos (explico por qué en cada uno):

1. Permita que el usuario ingrese la contraseña que desea. Esto va en contra de su pregunta, pero como dije, si obliga a su usuario a ingresar otra contraseña que no sea una de las 25 peores contraseñas conocidas, esto resultará en 1: Una mala experiencia de usuario, 2: Una contraseña probablemente perdida y todo " Perdí mi contraseña "flujo de trabajo. Ahora, lo que puede hacer es indicar a su usuario que esta contraseña es débil , o incluso agregar más detalles al decir que es una de las peores contraseñas conocidas (con una enlace a ellos), que no deberían usarlo, etc. Si detalla esto, inclinará a sus usuarios para modificar su contraseña a una más compleja porque ahora, ellos conoce el riesgo . Para el que usará 1234, permítales hacer esto porque quizás haya una razón simple: a menudo coloco una contraseña simple en algún sitio que solicita mi inicio de sesión / pase solo para ver qué me proporciona este sitio.

2. Agregue algunas reglas, como "Al menos un número y un carácter especial, debe tener un mínimo de 8", etc. Esto irá contra la peor contraseña. Por otro lado, si el usuario tiene una contraseña bastante compleja que no coincide con una de sus reglas, resultará en una mala experiencia de usuario.

Finalmente, debe elegir entre una buena experiencia de usuario o una mejor seguridad. Ahora realmente depende de qué tipo de proyecto está construyendo: si se trata de un sitio web básico para cargar fotos de títeres, tal vez no tenga que configurar un sistema de seguridad complejo. Pero si eres el próximo paypal, deberías.

Con respecto a su pregunta sobre la fuerza bruta, depende de cómo configure el almacenamiento de la contraseña. Si agrega sal y pimienta, se puede hacer fuerza bruta contra la base de datos. Si agrega un captcha en la página de inicio de sesión, o aumenta el tiempo entre intentos y errores, la fuerza bruta no será posible.

Es posible que el atacante use la peor contraseña primero, pero no estoy seguro de que sea bastante eficiente. Incluso si elige los primeros 3 (con respecto a sus reglas sobre captcha y 1-3 conjeturas), esto reducirá en gran medida la probabilidad de piratear una cuenta.

Lo que se está perdiendo aquí es que la mayoría de los ataques de contraseña, donde la complejidad es un problema (es decir, ataques que no involucran ingeniería social), sucede fuera de línea . Esto significa que el atacante ya tiene su propia copia de la base de datos de contraseñas y puede ejecutar el análisis en su propio sistema libremente sin preocuparse de que el sistema de destino los bloquee. Las políticas de bloqueo de cuenta y CAPTCHA son ineficaces contra estos ataques.

ataques de diccionario son mucho más rápidos que los ataques de fuerza bruta. Entonces, sí, es realista suponer que los atacantes buscarán contraseñas "comunes" antes de recurrir a la fuerza bruta. John The Ripper, quizás una de las herramientas de descifrado de contraseñas sin conexión más conocidas, incluso usa esto como una acción predeterminada. Por lo tanto, si su contraseña es "contraseña" o "12345678", es muy probable que se descifre en menos de un minuto. Una contraseña generada de forma aleatoria (o, al menos, no tan común) de igual longitud podría llevar bastante tiempo.

Depende de las necesidades de su aplicación y no es de una talla para todos. Si el escenario de compromiso del peor de los casos solo afecta al usuario final y es un inconveniente menor para ellos (y no es un inconveniente para usted), una simple advertencia educativa (esta contraseña es muy débil) y permitirles crear la contraseña débil probablemente sea suficiente.

Si su aplicación necesita ser segura como si fuera un banco, o usted es un comerciante en línea que guarda los detalles de la tarjeta de crédito del cliente ¹ (y significa que las devoluciones de cargo de la tarjeta de crédito son equivalentes a robo + cargos bancarios adicionales) ), o la cuenta tiene privilegios de administrador, o ..., debe hacer todo lo posible para evitar que las cuentas tengan contraseñas débiles y, por supuesto, no permitir ninguna contraseña popular. Yo crearía una base de datos ordenada de millones de contraseñas más populares tomadas de alguna fuente en línea (que también incluye el diccionario de inglés estándar), y verificaré las contraseñas además de verificar que cumpla con otros criterios mínimos; por ejemplo, debe tener más de 16 caracteres O más de 8 caracteres con un número superior + inferior +.

Las contraseñas muy débiles (top 1000) pueden ser atacadas aleatoriamente en línea por botnets (incluso si utiliza captchas / retrasos después de tantos intentos incorrectos). Los ataques de diccionario son fuera de línea muy rápidos si su base de datos hash se vio comprometida de alguna manera.

¹ Nota: una mejor solución puede ser no guardar los detalles de la tarjeta de crédito o al menos pedirles que vuelvan a escribir los detalles cada vez que intenten usar una nueva dirección IP.

Estoy seguro de que los atacantes usarán contraseñas comunes primero antes de comenzar un intento de fuerza bruta. Incluso si los dispositivos CAPTCHA (y otros dispositivos de detección / prevención) están en su lugar, la lista de contraseñas comunes es mucho más pequeña que las palabras en un diccionario.

Tomaré una postura diferente y sugeriré que tiene sentido rechazar contraseñas comunes en la mayoría de los casos de uso. La fuerza de una contraseña está ligada a la dificultad para que el adversario obtenga acceso no autorizado. Las cualidades que la comunidad acepta actualmente como una contraseña fuerte se basan en la dificultad para que un adversario obtenga acceso, ya sea por forzamiento de la fuerza bruta, craqueo u otros métodos (es decir, las frases de aprobación y los dispositivos mnemónicos aumentan la dificultad para un transeúnte para memorizar). XKCD representa esto con bastante precisión en este cómic . El uso de diferentes casos, símbolos, etc. aumenta la aleatoriedad de la contraseña de tal manera que el ataque tomaría más tiempo para ejecutarse con éxito y también aumenta la probabilidad de que se detecten intentos.

Mirando más de cerca los métodos de ataque, la contraseña del top 25, junto con muchas otras, se rellena comúnmente en los diccionarios. Los atacantes suelen estar interesados en las contraseñas comunes y, a menudo, intentan ejecutar la lista corta primero. Es similar a la práctica común de que muchos proveedores envían dispositivos con contraseñas conocidas (es decir, cisco / cisco, admin / admin) y no obligan al cambio de las credenciales predeterminadas conocidas. Desde la perspectiva del pago, generalmente vale la pena probar primero las contraseñas comunes. La única razón por la que un atacante podría no adoptar este enfoque es cuando el ataque está dirigido. En cuyo caso, el atacante puede ser más precavido porque no quiere lanzar banderas rojas.

Retrocediendo un paso, uso el término "atacante" de manera general. Un atacante puede significar un bot (o secuencia de comandos automatizada), un script para niños (no capacitados o menos capacitados) o una persona capacitada. Muchos argumentos de seguridad enturbian el terreno entre la protección contra el atacante automático / no calificado y experto. Aunque las técnicas utilizadas para detectar y prevenir a los atacantes automáticos / no calificados generalmente siguen el sentido común, es probable que el atacante experto esté al tanto de las estrategias tradicionales de detección / prevención y ajuste sus intentos de acuerdo con ello. Supongamos que me estoy refiriendo al atacante automático / no calificado a menos que califique el nivel de habilidad.

Tras el intento de ejecutar contraseñas comunes, los métodos de ataque en línea adicionales como la fuerza bruta son más difíciles de iniciar con éxito si existen sistemas adecuados de prevención o detección (es decir, registros de acceso / registros de auditoría, detección de fuerza bruta). Alternativamente, los métodos de ataque fuera de línea requieren acceso a un archivo de contraseña protegido, si un atacante puede obtener acceso a la información de la credencial (ya sea que esté bloqueada, encriptada o protegida de otro modo). Los evaluadores de lápiz (whitehats) a menudo siguen el flujo de trabajo de usar cuentas conocidas para obtener acceso inicial a un sistema para obtener un acceso más profundo a las redes. Independientemente, si un atacante tiene acceso sin conexión a un almacén de credenciales, hay problemas más grandes que las contraseñas.

La práctica de la seguridad realmente implica hacer concesiones con la accesibilidad. El sistema menos accesible es generalmente más seguro que uno más accesible. La persona de UX / UI lanzará historias para hacer sus vidas mucho más fáciles (sistema más accesible). La persona de seguridad tendrá que lanzar un sistema menos accesible. En última instancia, ambos tendrán que establecerse en una postura que sea aceptable por la BU / patrocinador. Combine el punto anterior con la tendencia de la mayoría de las personas a culpar (o quizás a la falta de voluntad para aceptar el fallo) y el principio de que la rueda más chirriante se engrasa primero. Si el usuario tiene un rango libre para elegir una contraseña, y un atacante obtiene acceso no autorizado y causa estragos, la primera respuesta de la "víctima" será "¿cómo sucedió esto?" Los dedos comienzan a señalar todo el lugar y, a menudo, acaban en la persona responsable de la seguridad con la pregunta: "¿por qué me dejaron elegir esta contraseña?" No estoy afirmando que esto sea común, pero la persona responsable de la seguridad es en última instancia responsable de seguir las políticas destinadas a proteger a los usuarios (y la marca / empleador). Mi punto aquí es que a veces no es una buena práctica dejar que los usuarios elijan sus contraseñas.

De nuevo, el valor de acceso depende del valor de la información proporcionada y la identidad del usuario.

  

¿Es realista asumir que los ataques se centrarán en contraseñas comunes antes de la fuerza bruta?

En mi experiencia, ese ha sido el caso. Aunque probar contraseñas comunes es solo un tipo diferente de "fuerza bruta".

La verdadera pregunta subyacente es la siguiente: ¿los atacantes intentarán un ataque exhaustivo contra una sola cuenta o intentarán un ataque muy superficial contra todas las cuentas?

La respuesta a eso depende de lo que quiera el atacante. Si quiere acceder a una cuenta específica (por ejemplo, una celebridad), entonces solo tendrá que luchar sin parar en esa cuenta; Es el único de valor para él. Pero si el atacante solo quiere acceder a cualquier cuenta, o al mayor número posible , entonces es mucho más razonable que pruebe solo las contraseñas más comunes en TODOS los cuentas.

En mi experiencia al examinar el código de ataque encontrado "en libertad" y actualmente en uso, el orden de las contraseñas es este:

1. Pruebe primero las contraseñas más comunes. Por lo general, hay una lista de entre 10 y 500 contraseñas para probar
2. Prueba las contraseñas del diccionario en segundo lugar. Esto a menudo incluye variaciones como la sustitución de "4" donde "A" sería o "1" donde estaba la letra "l", además de agregar números al final.
3. Agote el espacio de la contraseña, empezando por "a", "b", "c" ... "aa", "ab", "ac" ... etc.

El paso 3 generalmente se omite, y el paso 1 generalmente se intenta en un rango de nombres de usuario antes de pasar al paso 2.

Por supuesto, pero esa no debería ser la pregunta. La verdadera pregunta es: ¿Qué puedes hacer al respecto?

No mucho. Puede obligar a los usuarios a usar contraseñas más complejas que los harán escribirlos, alejarlos de su servicio o enojarlos (tengo una contraseña muy compleja con un carácter especial que algunos validadores de contraseñas simplemente no aceptan).

La raíz del problema es que las contraseñas son malas, sencillas y simples. Son una solución simple para un problema complejo ("¿Quién eres?") Y, como Einstein ya sabía hace 80 años, hay soluciones que son demasiado simples. Lo que los usuarios quieren es que su propia PC los identifique "de alguna manera" y que administre su identidad por ellos. Así que si puedes, no uses contraseñas en absoluto.

Prefiera soluciones de inicio de sesión único como OpenID , BrowserID o servicios similares. Esto le permite al usuario recordar una excelente contraseña en lugar de una mala para cada sitio o, peor aún, la misma contraseña para cada sitio.

Un atacante ejecuta las primeras 5000 contraseñas comunes y Brute fuerza la contraseña. Lo que puede hacer es hacer que la contraseña tenga al menos 9 caracteres, con mayúsculas, minúsculas y caracteres especiales.

Si está desarrollando un sistema, puede filtrar los datos al crear una cuenta. Debes usar el idioma del servidor y no el idioma del cliente para eso.

Si es un administrador del sistema de Microsoft, puede crear una Política de grupo y hacerla cumplir con las restricciones que mencioné, y también puede tener otras opciones como la longitud de la contraseña, la política de bloqueo de la cuenta y muchas más.

echa un vistazo a expresiones regulares.