¿Cómo debe ser manejado por un servicio la desactivación de 2FA?

TL; DR Es una cuestión de seguridad frente a usabilidad. Prefiero y defiendo la forma en que GitHub lo hace; Si el usuario ya ha iniciado sesión con una sesión de 2FA'd, solicite la contraseña al ingresar al área de cuenta "sensible" (cambio de dirección de correo electrónico o 2FA) y luego permita la desactivación de 2FA. Una vez desactivado, envíe un correo electrónico de notificación.

Esto es en gran parte una pelea entre el experto en UX y el experto en seguridad. Por un lado, si el tipo de seguridad / gal puede salirse con la suya, necesitarán la contraseña, el token de confirmación de correo electrónico, el token de 2FA y tal vez incluso un token de SMS además de eso. Pero eso solo disuadirá a los usuarios que probablemente mantengan 2FA deshabilitado para siempre después de pasar por ese horror de UX.

Si el usuario ya ha iniciado sesión con 2FA, es razonable asumir que esta sesión en este navegador no es iniciada por un atacante. Por lo tanto, requerir 2FA mientras se está en la misma sesión es excesivo. Sin embargo, solicitar la contraseña es una buena práctica, ya que el usuario puede compartir la máquina o dejarla desatendida. Así es exactamente como lo hace GitHub:

Si el usuario no ha iniciado sesión: siga el flujo regular de inicio de sesión de 2FA y continúe a continuación.

Si el usuario ya ha iniciado sesión con una sesión 2FA'd:

1. Usuario a punto de ingresar a la zona de peligro para deshabilitar 2FA:

2. Requieraquesevuelvanaautenticarconlacontraseña:

3. Dales la opción de deshabilitar 2FA con nada más requerido:

4. Finalmente, y muy importante, envíe al usuario una notificación por correo electrónico de que 2FA está deshabilitado.

Debido a la naturaleza de este cambio, a diferencia de cambiar la contraseña o habilitar 2FA, no creo que sea necesario aquí para forzar el cierre de sesión de todas las sesiones.

La respuesta aquí depende del apetito de riesgo y el perfil de amenaza de la organización. Como @adi señala, en este caso hay una compensación entre la usabilidad y la seguridad.

Para mí, permitir la eliminación de 2FA sin volver a ingresar algún tipo de credencial deja a las aplicaciones en riesgo, donde un atacante tiene acceso a una sesión activa (por ejemplo, mediante secuestro de sesión o en un entorno de PC compartido), por lo que es solo realmente adecuado para aplicaciones de menor riesgo (y la pregunta podría ser, ¿por qué tienes 2FA allí en primer lugar ...)

Entonces, la opción es, ¿qué es lo que necesita para volver a autenticarse para ejecutar la eliminación de 2FA?

Si solo permites una sesión autenticada con contraseña (el enfoque de github), entonces estás arriesgando ataques de tipo malware de PC en los que es probable que un atacante tenga una contraseña estática (a través de un registrador de teclas) y una sesión activa (a través de la eliminación de información el navegador), pero una vez que el atacante tiene acceso privilegiado a su sistema cliente, se encuentra en un lugar bastante malo, independientemente.

Otra opción sería requerir un token de reserva que se registró cuando se configuró 2FA. Sin duda, esto es malo para la experiencia del usuario (es muy fácil perder un token que usted configuró potencialmente hace años) y también se debilita cuando el usuario hace cosas como almacenar los tokens en el PC que se usa para iniciar sesión.

Una tercera opción es usar otro canal para confirmar la acción. Es probable que esto solo tenga sentido para los sistemas de mayor valor (por ejemplo, banca en línea, acceso privilegiado interno de la empresa). Aquí, el usuario es validado a través de otro mecanismo (por ejemplo, mensaje SMS, confirmación fuera de banda a través de una llamada telefónica)

No puede pedirles que se autentiquen con su segunda credencial porque eso crea un catch-22 para los usuarios que han perdido su segundo factor (por ejemplo, han colocado mal una ficha).

La eliminación de 2FA debe ser similar al flujo de contraseña olvidada. En ambos casos, el usuario ha olvidado o extraviado uno de sus factores; el flujo de trabajo para cambiar el factor, ya sea contraseña o 2FA, debe cumplir el mismo nivel de seguridad, pero no puede requerir la credencial o factor original.

Por lo general, este tipo de flujo implica la entrada de datos de factores alternativos (por ejemplo, dirección de correo electrónico y fecha de nacimiento, acompañados de CAPTCHA) seguidos de OOB OTP . Puede enviar un correo electrónico al usuario para restablecer un enlace o enviar un mensaje de texto con un código corto, por ejemplo.

En cualquier caso, los cambios en cualquiera de sus credenciales siempre deben activar una notificación por correo electrónico o SMS a tal efecto.