¿Forzar a los usuarios a usar una contraseña segura es efectivo?

Las preguntas específicas:

¿Este método sería más seguro / efectivo que permitir que los usuarios elijan el suyo?

Sí. Reducirá la reutilización de la contraseña y eliminará las contraseñas muy comunes de inmediato.

¿Alguien tiene alguna experiencia con la implementación de un esquema similar? ¿Fue efectivo?

He visto muchos esquemas de contraseña 'alternativos' en el pasado. La mayoría acaba de agregar problemas de soporte y complicaciones sin mejorar sustancialmente la seguridad.

¿Es beneficioso dividir el campo de contraseña en más de un campo distinto o expone demasiada información?

Creo que ya has derrotado los ataques automáticos básicos sin conocimiento simplemente por ser diferente. Eso deja un ataque dirigido. Sin embargo, si hay un registro público disponible, el atacante puede descubrir que necesita 5 palabras o lo que sea. Así que no creo que le proporcione más información al atacante dividiéndolo en campos.

Obviamente, no proporcione consejos sobre qué palabra (s) está mal, aunque si la autenticación falla, ¡eso socavará la seguridad!

Más consejos

Hay muchos otros buenos consejos en otras respuestas sobre usabilidad.

Si la seguridad y la facilidad de uso son importantes, quizás mire algo mejor que las contraseñas. SMS quizás?

Es posible desentenderse de las contraseñas durante años y aún no manejar los riesgos adecuadamente. Los troyanos en la computadora de los usuarios, el restablecimiento de la autenticación a través de las cuentas de correo electrónico que se piratean, el phishing ... hay cosas que ninguna cantidad de problemas con los esquemas de contraseñas de lujo y los controles tratarán *.

Si los datos son importantes, haría algo mejor que una contraseña.

(A veces, puede ser mejor simplemente generar una contraseña aleatoria para el usuario y pedirle que la guarde de forma segura en un cajón cerrado. Depende de las amenazas y los ataques que le preocupen y de cómo estará el sistema utilizado.)

* Hay mucho que decir acerca de la oferta de google basada en el riesgo de dos factores, donde la autenticación de dos factores se activa solo ocasionalmente. Controla los costos y da una gran mejora de seguridad. Pero lo subcontrataría a menos que tenga mucho tiempo en sus manos :)

Permitir cualquier contraseña. Solo resalta las consecuencias.

Su esquema es extraño y ajeno a los usuarios y creo que muchas personas prefieren dejar de usar su servicio en lugar de cumplir. En lugar de permitirles elegir su propia contraseña, los obliga a recordar la que eligió para ellos. Esto es inaceptable para la mayoría de las personas. Crees que les estás dando una opción al "intentar de nuevo", pero la diferencia en la experiencia del usuario es casi la misma que la de un bandido de ATM contra un bandido.

Tenga en cuenta que el mayor problema es el factor humano. Lo que debe evitar en primer lugar es que las contraseñas se escriban en una pizarra. Estos chicos tenían una contraseña muy segura Y luego se transmitido en TV.

Si desea asegurarse de que nadie a su lado pueda resolverlo, entonces lo que necesita son procedimientos internos, no usuarios de entrenamiento de monos. Tal vez un sistema donde el acceso a contraseñas con sal está protegido por los mismos límites de reintento que el panel de inicio de sesión del usuario. Además, no es importante hacer que sea imposible para los trabajadores obtener acceso. Los empleados de las tiendas tienen acceso ilimitado a las cajas registradoras. Lo que evita el robo es la conciencia de consecuencias inevitables. Utilice la grabación de la sesión de administrador. Utilice los procedimientos de "mínimo 2 personas para acceder". Así es como lo hacen los bancos, porque las contraseñas de usuario sólidas no pueden proteger todo.

Deberías leer sobre Diceware . Puede obtener 44 bits de entropía con cuatro palabras de una lista mucho más pequeña. Si su lista es de 2050 o más y selecciona sin reemplazo, cada palabra tendrá aproximadamente 11 bits de entropía porque log ₂ (2048) = 11. Con 5,000 palabras puede obtener 12 bits por palabra. (log ₂ (4096) = 12)

Me gusta la idea de un enlace "intente de nuevo" en el que el usuario pueda hacer clic hasta que aparezca una combinación que crea que pueden recordar.

Una cosa acerca de tu pregunta me molesta. Si los datos se cifran con la contraseña de un usuario en particular, solo ese usuario podrá descifrar los datos. Si sus datos se almacenan para cada usuario, eso puede estar bien. Tenga en cuenta que si un usuario olvida su contraseña, entonces los datos se tuestan si la contraseña es la clave de cifrado. Es posible que desee considerar un arreglo de claves asimétricas a la luz de esto.

Para acceder, no separe la entrada en cuatro campos. Eso le da a un atacante información que el atacante no debería tener. Simplemente decida si las palabras estarán o no separadas por espacios y comuníqueselo a sus usuarios.

El problema que veo con este enfoque es simplemente su naturaleza no convencional, lo que reducirá la probabilidad de que las personas lo utilicen.

Personalmente, tendría que tener una razón muy convincente para usar el servicio con el fin de soportar esto, en lugar de la entrada de contraseña tradicional. He comentado en el pasado que creo que los desarrolladores de aplicaciones tienen alguna responsabilidad para tratar de garantizar que los usuarios usen contraseñas seguras. Sin embargo; En última instancia, esto es responsabilidad del usuario.

También considera que estás obligando al usuario a emplear un método particular para asegurar la entropía de la contraseña. El enfoque de XKCD está bien, pero no es el único y no hay evidencia empírica absoluta de que sea el mejor, ni hay ninguna garantía de que si es el mejor hoy, seguirá siendo el mejor de los seis meses. ahora.

Considere el uso de administradores de contraseñas, que pueden generar contraseñas muy grandes y completamente aleatorias e ingréselas automáticamente para el usuario. Es probable que rompa esas aplicaciones con este enfoque.

También, considera cosas como el artículo de grc.com pajares de contraseña , que afirma que esto:

D0g.....................

... es una contraseña más segura que esta:

PrXyc.N(n4k77#L!eVdAfp9

... simplemente porque hay un carácter adicional, a pesar de que la entropía general (aleatoriedad) es bastante baja, y a una computadora le tomaría 95 veces más tiempo adivinar por fuerza bruta la contraseña que le sea más fácil de recordar. / p>

El problema es que los ataques de fuerza bruta solo se usan realmente hasta una cierta longitud de contraseña (de 6 a 8 caracteres) debido al gasto computacional ridículo a medida que las contraseñas se hacen más largas. Pero incluso las contraseñas cortas muy complejas son altamente vulnerables a la fuerza bruta. Los ataques más nuevos son ataques híbridos basados en patrones que utilizan contraseñas comprometidas como patrones dentro de contraseñas más grandes. Las potentes GPU hacen que este enfoque sea viable y, al parecer, es muy eficaz. Simplemente rellenar una contraseña débil con . 's no parece ser una buena solución.

También vea este artículo, Contraseña Las reglas de complejidad son más molestas, menos efectivas que las largas .

Entonces, al menos algunas investigaciones recientes indican que el factor más relevante en la fortaleza de la contraseña es la longitud de la contraseña, al menos en parte porque las contraseñas con mucha complejidad son demasiado para la mayoría de los usuarios, incluso si son cortas. El enfoque de XKCD ayuda a garantizar la longitud de la contraseña al hacer que sea fácil recordar contraseñas muy largas, sin que esas contraseñas sean patrones o frases bien conocidas. Esa es (probablemente) su máxima fortaleza, solo la longitud de las contraseñas resultantes. Habiendo dicho eso, estoy empezando a preguntarme cuánto tiempo "la carga correcta de la batería del caballo" soportará los nuevos ataques híbridos basados en patrones.

Dado que existen otros enfoques para lograr el mismo resultado, obligar a los usuarios a usar uno puede hacer que su servicio sea más difícil de usar sin una compensación proporcional en la seguridad. Además, si se encuentra alguna debilidad en el enfoque de XKCD dentro de seis meses a partir de ahora, está conectado a él y debe realizar un esfuerzo sustancial para cambiar su servicio.

Suena como una excelente forma de evitar la reutilización de la contraseña, aunque, como puede estar alejando a los usuarios de su zona de confort, puede hacer que guarden la contraseña en un archivo de texto para que puedan recordarla. Debe hacer hincapié en que el usuario debe recordar su contraseña, o usar un administrador de contraseñas para almacenarla de forma segura (si eso es algo aceptable para usted y su sistema). También me aseguraría de que la solución de campos múltiples funcione con los administradores de contraseñas comunes, aunque no puedo ver ningún otro problema al dividir las palabras de esta manera.

Como la funcionalidad del administrador de contraseñas con varios campos designados como la contraseña puede ser difícil de implementar, también le daría a los usuarios la opción de usar sus propias contraseñas, sin embargo, debe indicar que el usuario solo debe usar secuencias aleatorias generadas de forma segura, por ejemplo como los utilizados en los generadores de contraseñas incluidos en Keepass o LastPass. Para evitar que un usuario solo ingrese la misma contraseña que siempre usa, puede imponer una restricción tonta en el caso de que se ingrese para asegurarse de que sea realmente única. Por ejemplo. Mínimo de 50 caracteres, con al menos 20 números y debe incluir letras en minúsculas / mayúsculas y al menos un símbolo. Esto hará felices a los usuarios expertos, mientras evita contraseñas débiles de otros (aunque puede que algunos usuarios rellenen sus contraseñas débiles con 45 " 2" sy un" ! "). Podría intentar detectar casos como estos y luego refuerce el mensaje de que esta opción es solo para uso con generadores de contraseñas, sin embargo, los rendimientos se reducirán al poner tanto esfuerzo en los casos de borde. La mejor opción sería intentar y explicar a los usuarios no expertos que la opción de palabras generada es diferente. sería más beneficioso.

  

Estoy diseñando un servicio que, entre otras cosas, almacenaría información confidencial. Para garantizar que nadie de nuestro lado pueda recuperar esta información, se cifrará con una clave derivada de su contraseña (PBKDF2). La contraseña se almacenará en un formato de hash BCrypt salted en la base de datos. Nunca se almacena en texto plano.

Para que un cifrado basado en contraseña sea seguro contra ataques sin conexión (por ejemplo, las personas de su lado, o si un atacante obtuviera el acceso de otra manera), necesita una entropía de 128 bits o más, lo que significa que necesitaría diez palabras aleatorias para esto en lugar de cuatro o cinco. Aunque, como está utilizando PBKDF2 para reforzar la clave, esto le puede dar más o menos 16 bits de entropía adicional (dependiendo de iteraciones ), por lo tanto, solo se necesitan nueve palabras. Mi punto es asegurarme de que haces los cálculos para asegurarte de que tu encriptación sea adecuada.

Esto haría que a su usuario promedio le resulte aún más difícil recordar la frase de contraseña, y si utiliza un administrador de contraseñas, también puede optar por la opción de 50 caracteres y dejar que inicien sesión de esa manera. Como han señalado otros, parece que esto podría generar una gran cantidad de solicitudes de soporte y es un gran esfuerzo desarrollar solo una parte de un sistema seguro de autenticación y administración de sesión.

Tu método es interesante, pero creo que no me gusta.

1. Usted permite que los usuarios se "vuelvan a girar en la rueda" hasta que encuentren la contraseña que deseen. Si hicieras esto con números de cuatro dígitos, me temo que algunas personas podrían girar una y otra vez hasta que terminen con 1234 o 0000. Esto haría feliz al atacante.

2. Aunque hay muchas combinaciones, un atacante puede restringir el acceso a contraseñas solo de su estructura prescrita (y, de hecho, puede usar su servicio para determinar qué lista de palabras usa).

  

Al usuario se le presentarán 4-5 palabras diferentes de una gran lista de palabras con más de 6 caracteres (no se incluyen palabras con caracteres especiales, solo ASCII). El diálogo de entrada de contraseña se formatearía con 4-5 campos en lugar del campo único normal, para reforzar el paradigma de frase de contraseña. Al registrarse, la contraseña se puede regenerar a voluntad, para que el usuario pueda seleccionar una frase de contraseña que contenga palabras que puedan recordar fácilmente. El usuario no puede ingresar sus propias palabras.

Esto va a ser un problema.

Esto significa que debe tener una lista de las palabras que se están utilizando en la frase de contraseña y que no hay desviación de esa lista.

Si un hacker puede obtener la lista de alguna manera, ya sea por intentos de fuerza bruta o piratería social o cualquier otra forma, entonces tienen la lista de palabras y es mucho más fácil para ellos averiguar la contraseña.

Si, en cambio, lo hace para que un usuario pueda ingresar sus propias palabras y permitir números y / o caracteres especiales, la frase de la contraseña será mucho más segura y seguirá evitando que usen la misma contraseña que { en cualquier otro lugar } porque todavía estás forzando 4-5 palabras para la frase de contraseña.

Un par de cosas (algunas de las cuales ya se mencionaron)

1. Asegúrese de que las palabras no se repitan más de una vez
2. No les permita repetir una palabra más de una vez ( pass , word , pass , word )
3. No use la contraseña como clave para cifrar los datos
   • Esta es una muy mala idea, especialmente si el usuario olvida su contraseña y necesita un restablecimiento de contraseña.
4. No uses un password scheme
   • Esto deja pistas para que un hacker elimine palabras y frases, reduciendo el campo.

Antes de intentar implementar cualquier política de contraseña, realmente debería ver esta gran presentación de Rick Redman en AppSecUSA 2014 titulada "Los requisitos de complejidad de su contraseña no tienen ningún valor":

enlace

Habla sobre cómo descifrar contraseñas usando los patrones similares que todos los humanos usan para crear contraseñas.