Supongamos que tengo un sistema que usa algo que sabes, como una contraseña, y algo que tienes, como un código enviado a un teléfono celular, para autenticar.
¿Hay una orden preferida para solicitar la contraseña y el código?
¿Debería ser la contraseña primero y luego el código enviado al teléfono o lo contrario?
Editar
La respuesta debe ser:
Primero la contraseña, pero valida ambas al mismo tiempo.
Al volver a pensarlo, la respuesta debería ser:
Primero la contraseña, pero valida ambas al mismo tiempo.
Explicación
Como @woliveirajr mencionado , primero debes solicitar la contraseña o será muy molesto para un usuario. si un pirata informático intenta conectarse a su cuenta y recibe un SMS cada vez que intenta iniciar sesión. Por lo tanto, solo debemos enviar un SMS si la contraseña es válida.
Por otra parte, como @tylerl mencionado , para obtener la mejor seguridad que necesita, consulte a ambos al mismo tiempo. El truco que puede utilizar aquí es enviar solo el código SMS si la contraseña es correcta, PERO siempre solicite el código SMS durante el inicio de sesión, incluso si la contraseña era incorrecta.
De esta manera, el atacante no tiene forma de saber si la contraseña o el código SMS fue incorrecto Y no molesta al usuario real con un SMS en cada intento de falla / piratería.
No sé si hay algún estudio al respecto, o si esta pregunta se cerrará según la opinión, pero:
En un ataque en línea, limitarás la cantidad de intentos que puedes hacer por cada x minutos, o incluso bloquearás la cuenta después de los intentos de x . Entonces, un ataque de fuerza bruta tendrá un impacto limitado. De todos modos, una contraseña probablemente tendrá más combinaciones que el código que enviarás por SMS. En general, los códigos de envío de SMS tienen 4 caracteres o 6 dígitos.
Si alguien está tratando de imponer una fuerza bruta y usted envía el SMS primero:
si tiene que adivinar el código, y el código es más pequeño que la contraseña, es más fácil adivinar 6 dígitos que una buena contraseña.
si envía SMS para cada intento, el usuario real puede aburrirse al recibir tantos códigos que no solicitó, y hay poco que pueda hacer al respecto (cómo decirle al sitio que deje de aceptar intentos de ¿El chico malo?)
Si primero solicita la contraseña, no molestará al usuario real hasta que la cuenta esté bloqueada por tantos intentos. Y después de que la cuenta esté bloqueada, puede enviar simplemente el SMS que dice "su cuenta fue bloqueada debido a intentos incorrectos de x , para desbloquearla, consulte su correo electrónico"
Y tal vez el envío de SMS puede costarle algo, puede ser menos costoso enviar el SMS como último paso.
En el caso ideal, ambos se pueden ingresar al mismo tiempo, como en el caso de un generador de OTP . De esta manera, está probando la combinación de la contraseña y la OTP al mismo tiempo, sin revelar cuál fue el error, lo que evita que un atacante ejerza una fuerza bruta que lo ataque de forma aislada.
Pero debe tener en cuenta las preocupaciones prácticas en escenarios como la verificación basada en SMS. En tal caso, un atacante puede usar el sistema para atacar al usuario. Si puede activar un mensaje SMS al intentar una autenticación, incluso sin conocer la contraseña, entonces con el tiempo podrá molestar al usuario para que desactive la autenticación de segundo factor solo para detener los mensajes SMS. La limitación de velocidad por parte del servicio de autenticación probablemente no sería suficiente para evitar este tipo de ataque.
Entonces, como compromiso, se requiere un nivel mínimo de permiso para activar el ciclo de verificación fuera de banda, ya sea por SMS, correo electrónico o llamada telefónica u otro. Esto no es ideal, ya que permite que la contraseña se ataque de forma aislada, pero la compensación general se considera valiosa.
Otra consideración es la divulgación de información. ¿Cuánta información sobre la configuración de autenticación de un usuario desea divulgar a un atacante no autenticado? Si se requiere un segundo factor, entonces es razonable requerir el token del segundo factor por adelantado. Cada usuario lo tiene, por lo que no se revela nada personal. Pero si el segundo campo de factor solo es visible si escribe el nombre de usuario de un usuario que lo tiene habilitado, entonces un atacante puede decir rápidamente si el segundo factor está habilitado sin necesidad de conocer la contraseña. Tal vez eso es un gran problema, tal vez no lo es. Pero vale la pena considerarlo, ya que esa información podría usarse para elegir un objetivo para las campañas de phishing.
Siempre voy con la contraseña primero; esto garantiza que no cualquier persona puede solicitar que se envíen tokens de autenticación de SMS o correo electrónico a los usuarios al azar simplemente haciendo clic en un botón.
En algunos casos, estos servicios pueden ser costosos y molestos.
Lea otras preguntas en las etiquetas authentication