Restablecimiento automático de contraseña: ¿es una buena idea?

Probablemente no sea una buena idea porque si quisiera evitar que Bob inicie sesión, puedo seguir enviando solicitudes de inicio de sesión automatizadas para el usuario [email protected] a su servicio con cualquier PIN.

Además, no se recomienda enviar contraseñas / PIN por correo electrónico porque la bandeja de entrada de un usuario no es un lugar seguro para el almacenamiento de esta información confidencial.

Es más seguro en el sentido de que en cada 20 conjeturas se genera un nuevo PIN, lo que significa que el atacante solo tiene una probabilidad de 20 / 1,000,000 (1 / 50,000) de adivinar correctamente.

Una alternativa que evita el problema de DoS es que podría introducir la verificación de correo electrónico para los inicios de sesión que tienen más de 10 inicios de sesión fallidos en la última semana. p.ej. cuando ingresan la combinación correcta de nombre de usuario y PIN, se envía un correo electrónico a su cuenta registrada que contiene un enlace con una cadena aleatoria. El usuario debe hacer clic en ese enlace de correo electrónico para completar el inicio de sesión en su sistema.

Incluso si el dispositivo con la restricción de hardware no puede ver el correo electrónico, otro dispositivo que también puede ingresar el PIN pero recibir el correo electrónico podría "responder" de esta manera.

Como ilkkachu notes , Sería aconsejable calificar los intentos de inicio de sesión límite con el mismo nombre de usuario. Sin embargo, como el número de PIN posibles es de 1.000.000, incluso con un retraso de 20 segundos en promedio, un atacante podría obtener acceso después de aproximadamente 17 semanas de intentos constantes de inicio de sesión. Por lo tanto, agregaría 2FA para proteger cuentas o implementaría la verificación por correo electrónico de inicios de sesión sospechosos en combinación con la limitación de la tasa.

No hay problema con esto, pero una mejor solución en su caso es usar un "PIN de hardware" aleatorio que se usa solo cuando se comunica con el "hardware estúpido", que se almacena dentro de la cuenta, posiblemente encriptado con un hash del usuario. contraseña. (y para verificar la contraseña al iniciar sesión, use el hash (hash ()) de la contraseña). Por lo tanto, puede usar una contraseña normal para la interfaz web y, por lo tanto, no es necesario imponer límites de prueba estrictos. (en su lugar, puede imponer un límite de prueba cronometrado)

Yo diría que es una buena idea. Si puede crearlo de modo que si hay un cierto número consecutivo de intentos de PIN incorrectos, ya que la fuerza bruta se pondrá MUCHA al principio, puede codificarlo para que el script lo note, y solo enviará uno correo electrónico. Esto ahorra a sus servidores el manejo de demasiados correos electrónicos innecesarios. También implementaría que la IP de la que el usuario está tratando de ejercer una fuerza bruta, si usted puede identificar tendrá bloqueadas sus conexiones entrantes, por lo que no podrá conectarse a usted en absoluto. Si puedes hacer esto, diría que es un método realmente bueno.

Otra cosa que tendrías que tener en cuenta es que si el usuario que intenta hacer fuerza bruta, digamos, supiera que esta función se implementó en tu sistema PIN, podría, más o menos, realizar un ataque MITM y, con suerte, capturar El correo electrónico antes de que llegue al destinatario especificado. Entonces cubra todos sus extremos y asegúrese de que su red se comunique con SSL encriptado, utilizando cosas como TCPCrypt, etc.

Ah, y la gente normalmente no tiene que volver a ingresar su contraseña 20 veces, diría 10. Pero eso depende de usted, puede poner cualquier cosa para eso.

Por un lado, supongo que el sistema que está planeando es para un caso de uso limitado, ya que no creo que sea imposible exigir un poco más de las contraseñas en el uso general: incluso Stackexchange requiere ocho caracteres con números.

En cierto modo, un millón de códigos posibles es a la vez muy pequeño y lo suficientemente grande. Si un atacante obtiene su base de datos de contraseñas y puede intentar descifrar los hashes fuera de línea, desaparecerán en un instante. Incluso si el hashing fuera lo suficientemente lento como para permitir solo probar diez códigos por segundo, todo el espacio de teclas se completaría en un poco más de un día. No va a ser tan lento.

Por otra parte, ya que puede limitar los intentos de inicio de sesión en línea, debe ser bastante controlable. Para obtener solo un 1% de adivinar un código de acceso, el atacante necesitaría 10000 intentos. Eso no debería ser habitual, especialmente desde una IP de una sola fuente o contra una sola cuenta, y debe bloquear la fuente en ese momento y considerar bloquear la cuenta. (Si tienes muchos usuarios y eres atacado por una botnet, entonces es más difícil de detectar).

Aunque con códigos de dígitos, usted debe hacerlos aleatorios, en lugar de dejar que el usuario decida. De lo contrario, solo elegirán las fechas, haciendo que el espacio clave efectivo sea más pequeño. Ya has tocado esto cuando planificaste un reinicio aleatorio, pero para empezar tiene que ser aleatorio, de lo contrario, descubrir los cumpleaños de las personas será demasiado rentable.

En cuanto al cambio automático del PIN, heck no. Además del spam que otros han mencionado, también podría bloquear al usuario legítimo si no puede acceder a su correo electrónico en el momento adecuado. Y si lo hace no con limitación de velocidad, no tendrán tiempo para leer su correo electrónico antes de que el atacante haya realizado otros 20 intentos y el código vuelva a cambiar ... Entonces, nuevamente, si do limitante de velocidad, podría bloquear la cuenta a propósito durante un tiempo.

Por supuesto, el bloqueo de cuentas es un vector de DoS, pero es un compromiso que debe elegir. ¿Quieres priorizar el bloqueo de los malos o asegurarte de que entren los buenos?

¿El cambio automático haría que el código sea más difícil de adivinar? Bueno, sí, marginalmente. Para un código de acceso invariable, tendría K en N posibilidad de adivinarlo, al hacer K adivina contra N códigos posibles. Para un código cambiante, la posibilidad de adivinar es una constante 1 / N para cada estimación, o 1- (1-1 / N) ^ K para K estimaciones. Calcula alrededor de 500000 contra 700000 para una probabilidad del 50% de hacerlo bien. Es más, pero en la misma escala. ¿Desea permitir esos cien mil intentos de inicio de sesión en primer lugar?

Sería una idea muy similar enviar al usuario un correo electrónico de 'restablecer PIN' cuando presione 'Olvidé mi PIN' en el sitio web, pero en lugar de enviarle uno aleatorio, tal vez le dé al usuario una opción para configurar hay propia? Eso parece ser el método estándar. Podría bloquear allí la cuenta después de que X intente forzarlos a usar la opción de restablecer PIN.