Hagamos que el usuario use una contraseña segura

Érase



una vez suficiente tener una abuela malvada en la entrada de la sala de máquinas para proteger la contraseña Hace mucho tiempo, en los días de los primeros mainframes, existía una excelente autenticación de dos factores. Antes de ingresar su contraseña personal en la terminal, era necesario pasar por la caseta con un guardia. Todo esto redujo automáticamente la superficie de ataque a unas pocas personas que tenían acceso físico a la terminal. Fue entonces cuando aparecieron los módems, el hash y otras alegrías del mundo moderno, cuando las contraseñas se filtran regularmente por millones.



Si tiene usuarios que inician sesión con una contraseña, le sugiero que revise las últimas recomendaciones de organizaciones como el Instituto Nacional de Estándares y Tecnologías y el Centro Nacional de Seguridad Cibernética .



En particular, ya no está de moda exigir la rotación de contraseñas. Y exigir también ciertos símbolos en las mejores tradiciones del chiste sobre "FUCKING ROSE". Repasemos los puntos principales y tratemos de hacer que los usuarios sean más convenientes y seguros.

La autenticación no es binaria

No, entiendo que los partidarios de formulaciones estrictas ahora comenzarán a resentirse. En teoría, el usuario está conectado o no. No podrás iniciar sesión un poco. Sin embargo, las guías modernas de seguridad de la información implican un enfoque no binario de la confianza del usuario.



Un usuario de confianza perfecta logró ingresar la contraseña correctamente e inicia sesión desde un dispositivo autorizado. Un poco menos de confianza en un usuario que inició sesión desde un dispositivo confiable, pero cometió un error al ingresar la contraseña. Y es realmente malo si el usuario ingresó la contraseña correctamente, pero el dispositivo no es de confianza, el segundo factor no está confirmado y la IP pertenece al nodo de salida de Thor. En el tercer caso, es hora de accionar el interruptor con la inscripción “¡Alarma! ¡El lobo robó los conejos! "



Nuestra tarea, como personas que brindan el servicio, es hacer que las personas se sientan cómodas, seguras y no muy dolorosas si cometen errores. Por lo tanto, vale la pena colocar ciertos signos de actividad anormal con el fin de incluir ciertas medidas adicionales para proteger la cuenta. Por ejemplo, después de 3-5 entradas de contraseña incorrectas, solicite al usuario que realice el CAPTCHA. Sí, todo el mundo lo odia, pero la mayoría de los usuarios no lo encontrarán. Y aquellos que rebajaron su calificación de confianza simplemente reducirán un poco la velocidad antes de ingresar la contraseña nuevamente. Pero cortaremos los ataques automáticos de fuerza bruta.

No es necesario limitar la longitud máxima de la contraseña

Las contraseñas largas son más seguras. Deje que los usuarios los utilicen.



Bueno, no es que no sea necesario en absoluto. Las contraseñas en negrita de varios megabytes de longitud pueden ser potencialmente contraproducentes en lugares inesperados u otros efectos extraños. Pero la longitud máxima condicional de 300 caracteres está garantizada para adaptarse a cualquier usuario típico. Además, NIST se adhiere a las mismas recomendaciones:

El autenticador debe permitir que el usuario use contraseñas memorables de al menos 64 caracteres.

Y para los servicios especialmente dotados, NIST también ofrece otra recomendación importante:

No se permite truncar la contraseña del usuario.

Sí, hay servicios extremadamente extraños que creen que 12 caracteres serán suficientes, lo que significa que los 28 restantes se pueden cortar de forma segura y verificar el hash de solo el primer fragmento. No sé qué pensó la mente afectada de esto, pero las mismas organizaciones bancarias a menudo sufren de esto. No hagas eso. Si un usuario quiere usar una pieza de Iliad por la mitad con fragmentos de textos del grupo Bloodstock, déjelo usar.

Asegúrese de que los caracteres ASCII sean válidos

Hay ciertos problemas con los caracteres especiales. Por ejemplo, el uso de "{} / \" u otros caracteres similares puede no ser válido en algunas situaciones. Digamos que las llaves pueden romper JSON válido y hacer que el procesamiento de contraseñas se bloquee. O el carácter de apóstrofo, que se puede utilizar en la inyección SQL. Sí, el formulario de entrada de contraseña también puede ser una puerta de entrada para un ataque.



En teoría, simplemente podría prohibir el uso de tales símbolos para que sea más fácil para usted. Pero al hacerlo, reducirá la entropía de la contraseña del usuario y le resultará inconveniente si la contraseña se genera automáticamente. Deberá seleccionar ciertos patrones para las excepciones. Nuevamente, refiriéndose a NIST Marx :

Todos los caracteres ASCII [RFC 20] imprimibles, incluido el espacio, deben ser contraseñas válidas. Los caracteres Unicode [ISO / ISC 10646] también deben ser válidos.

Si. Todo es correcto. Este es su dolor de cabeza y pruebas adicionales. Pero si el usuario quiere usar ਬਹੁਤ ਮੁਸ਼ਕਲ ਪਾਸਵਰਡ o මෙයද ඉතා දුෂ්කර මුරපදයකි, déjelo que lo haga. O agregue un carácter de burrito a su contraseña para mayor seguridad criptográfica. Tiene el derecho de.



Además, quédese detrás del usuario con el requisito de usar caracteres especiales. Sí, simplemente no lo toques. Déjelo usar lo que quiera. Los estudios de filtraciones masivas sugieren que la gente todavía usa sustituciones estúpidas con caracteres especiales, lo que no mejora la situación en absoluto. Específicamente, Microsoft escribe:

La mayoría de la gente usa el mismo patrón, por ejemplo, una letra mayúscula como primer carácter, caracteres especiales y números en las dos últimas posiciones. Los ciberdelincuentes son conscientes de esto y personalizan sus ataques de diccionario con sustituciones típicas como "s" por "$", "a" por "@" e "i" por "l".

Sí, el mismo Microsoft, por lo que a millones de personas cada mes se les ocurre una nueva contraseña que no coincide con las anteriores, que contiene caracteres especiales y letras en diferentes mayúsculas. Ellos son los que ahora escriben "Eliminar los requisitos de composición de personajes" en sus pautas.



Después de todo, al final, las utilidades típicas como cain y abel, hashcat, john the ripper pueden adivinar una contraseña en unas pocas horas o incluso minutos en una tarjeta de video típica, si se usa una palabra de vocabulario estándar y un patrón de reemplazo típico.

No utilices sugerencias de contraseña

Es mucho más seguro enterrar una contraseña olvidada para siempre que almacenar una pista para el usuario en texto sin cifrar en la base de datos.



En 2013, Adobe filtró su base de datos de contraseñas. Estaba encriptado torcidamente, pero lo más desagradable era que contenía pistas para la recuperación, que Randal Monroe no dejó de burlarse en xkcd.

NIST comparte la misma opinión, que no recomienda almacenar sugerencias de ninguna forma. Olvidó: restaure por correo con todos los controles adicionales.

Reducir la carga en el cerebro del usuario

El Centro Nacional de Seguridad Cibernética ha publicado una interesante infografía . Permítanme citar un pequeño pasaje:



Tenga en cuenta que el principal problema con las contraseñas es que una buena contraseña es aleatoria y casi imposible de recordar. Si hay muchos servicios, el usuario utilizará casi inevitablemente la misma contraseña siempre que sea posible. Los más avanzados harán algo como "myp@ssword_habr.com". Naturalmente, comprometer una contraseña en un lugar compromete automáticamente las cuentas de todos los demás servicios.

Por lo tanto, permita que el usuario use administradores de contraseñas. Sí, es como una billetera especial para tarjetas bancarias que te permite perderlas al mismo tiempo. Pero aquí debe comprender que el compromiso de un almacenamiento de contraseñas fuera de línea es una situación bastante rara, en contraste con el compromiso de las mismas contraseñas en diferentes recursos. Un administrador de contraseñas no tiene por qué ser perfecto. Debe ser mejor que el mismo tipo de contraseñas en todas partes. No seas como un servicio desagradable que bloquea la posibilidad de pegar una contraseña en un campo del portapapeles. Esto claramente obliga al usuario a abandonar el administrador de contraseñas y utilizar la opción débil.



El segundo punto dice que no es necesario obligar al usuario a cambiar su contraseña si no hay signos evidentes de su compromiso. Esto solo lo motiva a usar el patrón con la misma contraseña. Es mucho mejor dar la alarma si la contraseña aparece en uno de los muchos diccionarios filtrados. Naturalmente, no puede permitir que el usuario cree una contraseña que ya se haya incluido en los diccionarios.

conclusiones

1. Sea más amable con el usuario. No lo obligue a inventar patrones típicos y a hacer cosas estúpidas. Los requisitos habituales estándar lo empujan directamente a esto. Solo sigue algunos puntos:
2. Utilice autenticación de clave en lugar de contraseñas cuando corresponda.
3. No permita que el usuario use una contraseña si está en las bases de datos del diccionario. No importa si los filtró allí o alguien más.
4. , . . .
5. , .
6. , .