Autentificación del código de correo electrónico

2

Me gustaría reemplazar las contraseñas con un código temporal que se envía por correo electrónico al usuario. El flujo de inicio de sesión sería así:

  1. El usuario ingresa su dirección de correo electrónico. "Si ese correo electrónico pertenece a un usuario, se enviará un código" para evitar la divulgación de correos electrónicos válidos.
  2. El usuario recibe un código alfanumérico por correo electrónico (digamos 8 dígitos de longitud y es válido por 1 hora).
  3. El usuario ingresa ese código como su "contraseña".

El bien:

  1. No se almacenan contraseñas en la base de datos.
  2. No es necesario restablecer la contraseña.
  3. Gran parte de la carga de seguridad se transfiere al proveedor de correo electrónico.

Lo malo:

  1. Se requiere una dirección de correo electrónico. Si pierde el acceso a él, perderá el acceso a su cuenta.
  2. Si olvida su dirección de correo electrónico, perderá el acceso a su cuenta.
  3. Es inconveniente revisar su correo electrónico cada vez que inicie sesión. Esto no sería un problema en el dispositivo móvil, donde se puede almacenar un token de API después del primer inicio de sesión.

¿Hay otros problemas, especialmente relacionados con la seguridad? Por lo que puedo decir, esto debería ser tan seguro como restablecer una contraseña. En ambas situaciones, se le envía un mensaje de correo electrónico que permite el acceso total a la cuenta.

Aquí hay preguntas similares pero con más enfoque en las cookies o sin respuestas sólidas. Me interesan más los aspectos positivos y negativos, especialmente los problemas de seguridad.

Edición de claridad / objetivos: Los objetivos son limitar la cantidad de datos confidenciales almacenados en la base de datos (incluso si los datos están ocultos), ser accesible para los usuarios promedio (de forma remota con una conexión a Internet) y no depender de un dispositivo diferente para la autenticación. Además, sea lo más simple (UX) y seguro posible dadas esas restricciones.

    
pregunta emeraldgreen 16.04.2016 - 20:54
fuente

1 respuesta

2

tl; dr: Todo se reduce a lo buenos que son los usuarios para mantener seguros sus correos. Pero eso son postales en lugar de cartas. No exclusivamente ofrezca esa opción. Además, parece un xy problem .

Aquí hay algunas cosas que deben considerarse al respecto:

  • Has dicho

      

    El usuario recibe un código alfanumérico por correo electrónico (digamos 8 dígitos de longitud y es válido durante 1 hora).

    Más bien digamos 20 bytes, válidos por 10 minutos. La fuerza bruta de una contraseña de 8 dígitos es absolutamente factible.

    Esto se puede pasar a la aplicación / aplicación web a través de una solicitud de obtención desde un enlace en el correo electrónico para facilitar la vida del usuario.

    Eso es lo que Slack está haciendo con su función de "enlace mágico", por cierto.

  • Has listado como negativo

      

    Se requiere una dirección de correo electrónico. Si pierde el acceso a él, perderá el acceso a su cuenta.

    y

      

    Si olvida su dirección de correo electrónico, perderá el acceso a su cuenta.

    Este suele ser el caso, al menos con restablecimientos de contraseña.

  • Aún puede usar cookies de sesión en la aplicación web para mantener al usuario conectado durante más tiempo, igual que almacenar ese token en una aplicación móvil.

    De ahí este problema

      

    Es inconveniente revisar su correo electrónico cada vez que inicie sesión.

    se ha ido.

  • Tu lista como positiva

      

    Gran parte de la carga de seguridad se transfiere al proveedor de correo electrónico.

    aunque, de hecho, gran parte de la carga de seguridad se transfiere al usuario también.

    ¿Qué tan seguro está de que sus usuarios solo revisan sus correos electrónicos a través de conexiones seguras, sin posibilidades de escuchas ilegales? (Piense: abra WiFi, POP regular en dispositivos móviles. Sucede todos los días .)

    Esto hace que el buzón de correo del usuario sea un punto único de falla.

    Además, aunque me han pwned es conocido por la mayoría de las personas afines a la TI, hay un montón de las personas que no saben que su correo electrónico ya está violado debido a la reutilización de la contraseña .

    Sin embargo, el último punto también es válido para los correos electrónicos de restablecimiento de contraseñas: solo ocurren con menos frecuencia y, por lo general, activan medidas de seguridad adicionales.

Por cualquier motivo que esté intentando usar correos electrónicos y contraseñas de corta duración, hay mejores formas, por ejemplo, tokens de seguridad UBS que agregan a "en algunos casos solo usted tiene" parte de la ecuación, sin eliminar una parte "algo que solo tú sabes" .

También le aconsejo que piense si esto podría ser una instancia de un xy problem y haga una nueva pregunta con el problema real usted está tratando de resolver.

Actualización para la pregunta modificada:

Si las contraseñas son hash correctamente , no hay nada de malo en almacenar en tu base de datos.

Sin embargo, si aceptamos como decisión de UX que el usuario no tenga contraseñas, usar el correo electrónico y solicitar a los usuarios la clave GPG y / o el certificado S / MIME y enviar enlaces de contraseña de corta duración al usuario mediante correo a petición. estaría bien.

    
respondido por el Tobi Nary 16.04.2016 - 21:44
fuente

Lea otras preguntas en las etiquetas