¿Cuáles son los riesgos de seguridad de una autenticación basada en teléfono?

2

Estaba buscando una manera de hacer que la experiencia de autenticación sea lo más simple posible y este proyecto vino a mi mente, donde Google estaba usando la cuenta registrada en su teléfono para iniciar sesión en su navegador.
De todos modos, después de 4 años, no lo he visto convertirse en algo real.
El único ejemplo en el que puedo pensar es en la aplicación de escritorio de WhatsApp.
Me preguntaba si esto está relacionado con algunos problemas de seguridad que no estoy considerando.

    
pregunta pasine 04.11.2016 - 14:07
fuente

2 respuestas

1

No veo ningún problema de seguridad con este enfoque, simplemente utiliza una sesión ya existente (su sesión de Google en su navegador móvil) para aprobar una solicitud de inicio de sesión para una nueva sesión.

Facebook hace algo similar: cuando habilitas 2FA, se comporta como es de esperar, pero si tienes su aplicación móvil, recibes una notificación y puedes aprobar el inicio de sesión desde la aplicación sin tener que ingresar una OTP en la página de inicio de sesión.

Creo que no se ha disparado debido a problemas de uso y desventajas en comparación con las PTO estándar. En ambos casos, debe sacar su teléfono, pero con este sistema también debe tomar una fotografía del código QR y luego estar conectado a una red para acceder a la URL. El antiguo TOTP es igual de seguro pero sin esos inconvenientes.

Finalmente, esto tiene como objetivo frustrar el malware en las máquinas que no son de confianza, pero el problema es que, sin importar cómo inicies sesión, la computadora comprometida todavía podría usar y abusar de tu cuenta de cualquier forma que quiera, ya que tendrá acceso a un registro. en sesión. La forma en que inició sesión no importa mucho si aún puede obtener acceso y obtener todos sus datos personales.

    
respondido por el André Borie 04.11.2016 - 14:54
fuente
1

Veo un riesgo de seguridad con la "aprobación de solicitud de inicio de sesión" sin ningún código QR, que se usa hoy, y es que la aprobación de inicio de sesión no está vinculada de ninguna manera a la sesión en la computadora que está utilizando.

Ergo, si un usuario es engañado de alguna manera para que acepte una solicitud de inicio de sesión que no sea suya, la cuenta está comprometida.

Para tomar 3 ejemplos:

Ejemplo 1: si un usuario inicia sesión, pero inmediatamente antes, un atacante intenta iniciar sesión. El usuario recibirá una solicitud de inicio de sesión, cree que es "su" inicio de sesión, pero en realidad, está aprobando el del atacante.

Ejemplo 2: un atacante envía un correo electrónico falso. Al hacer clic en el enlace de este correo electrónico falso, se accede a una página HTML estática que simplemente le dice al usuario que apruebe el inicio de sesión en el teléfono. Tan pronto como se carga esta página HTML estática, el atacante detecta esto e intenta iniciar sesión. El problema con esto es que el atacante no necesita ejecutar ningún código ni recopilar ninguna información, lo que significa que se pueden usar páginas HTML completamente estáticas. Es poco probable que estas páginas generen alertas en los sistemas de suplantación de identidad (phishing) y, además, otro problema es que el atacante puede usar un alojamiento anónimo y no rastreable, incluso si el alojamiento bloquea los scripts / páginas dinámicas por completo, o incluso un XSS no persistente reflejado de alguna otra página, podría utilizarse para "alojar" la página de phishing. Esto también significa que es poco probable que el host elimine el contenido (como "Hemos bloqueado las etiquetas de formularios y secuencias de comandos para que nadie pueda alojar phishing aquí de todos modos").

Ejemplo 3: una variante del ejemplo 2, pero aquí, el atacante escribe directamente en el cuerpo del correo electrónico que, por algún motivo, debe aceptar la solicitud de inicio de sesión. Luego, el atacante carga una pequeña imagen de 1x1 para detectar cuándo se lee el correo electrónico, y luego intenta iniciar sesión.

Para mitigar:

Requiere que el usuario ingrese algún tipo de "desafío" o "ID de sesión" para responder a la solicitud de inicio de sesión. O bien, esto se puede hacer solicitando al usuario que ingrese un código aleatorio en el teléfono, como "Ingrese el código 6236 en el teléfono para aprobar la solicitud de inicio de sesión" y luego en el teléfono aparece "Ingrese el código que se muestra en la pantalla para aprobar: "+ cuadro de entrada. Un código QR que debe ser escaneado también es otra excelente alternativa para asegurar una conexión entre la solicitud de inicio de sesión en la computadora y la solicitud de inicio de sesión en el teléfono. Esto es aún más seguro, ya que garantiza que existe una línea de visión entre el dispositivo que inicia sesión y el dispositivo conectado.

O esto se puede hacer completamente fuera de banda usando algún desafío-respuesta donde el usuario ingresa un desafío, luego esto se califica con respecto a algún secreto almacenado, luego se puede mostrar una respuesta en la pantalla del teléfono, que debe ser ingresado en el sitio web para proceder.

Es por esto que un esquema basado en QR es más seguro.

    
respondido por el sebastian nielsen 04.11.2016 - 17:03
fuente

Lea otras preguntas en las etiquetas