El problema relacionado con MITM con SQRL se deriva del hecho de que la solicitud y respuesta de autenticación ocurren a través de dos canales diferentes, y un atacante puede llevar a cabo con éxito una solicitud / respuesta de autenticación válida desde un sitio inválido Es decir, un sitio de ataque podría obtener un código SQRL del sitio correcto y presentarlo a la víctima. La víctima puede autenticarse contra la solicitud proporcionada, pero al hacerlo, iniciará sesión en el atacante en su lugar. La falta de coordinación entre el navegador y el teléfono significa que no puede proteger este paso.
En este sentido, SQRL no es más susceptible a phishing / MITM que las contraseñas, y es algo mejor en el sentido de que la autenticación tiene que ocurrir en línea. Pero es peor que las alternativas existentes, y ese es el problema.
Entonces, por ejemplo, si tu madre o jefe o compañero de trabajo o amigo te dice: " Quiero estar más seguro en línea, ¿debo usar SQRL? " Tu respuesta debe ser: " No, use las contraseñas de Lastpass y aleatorias en su lugar "
La diferencia fundamental aquí es que la integración del navegador frustra todos los ataques de phishing, y como el phishing es, con mucho, la amenaza más grave para su seguridad en línea, esta debería ser su primera prioridad, superando todo lo demás. No se debe considerar una alternativa si no protege contra esta amenaza, porque es la que es más probable que enfrentemos. Si vas a cambiar, cambia a algo que te mantenga seguro, no a algo que no lo haga.
¿Qué hay de las contramedidas de GRC?
El primer punto de GRC acerca de cómo los códigos SQRL son únicos para un sitio determinado es irrelevante, y no estoy seguro de por qué le molesta mencionarlo. Básicamente, está diciendo que paypal.evil no puede generar su propio código SQRL para paypal.com. El atacante tendría que obtener un código auténtico de paypal.com y presentarlo al usuario. Que es exactamente lo que harían.
La contramedida "Redirección de inicio de sesión" es realmente solo factible si está utilizando la integración del navegador ... en cuyo caso es completamente innecesario, ya que el navegador ya puede indicar si está en el sitio correcto o no. Si está utilizando SQRL con un teléfono como se diseñó originalmente, entonces el enlace de "redirección de inicio de sesión" deberá escribirse manualmente en la URL alguien que lo lea desde el teléfono. Entonces ... eso no va a suceder.
La contramedida "Confirmación de acción" es una carga de tonterías. La idea es que inicie sesión en el banco con SQRL, luego todas las actividades (incluida la visualización de datos confidenciales) realizadas en el sitio web del banco deberán confirmarse manualmente en el teléfono celular. Sería como usar la aplicación de teléfono celular del banco, pero con un inconveniente adicional.
El material de verificación de ip-fuente sobre el que GRC entra en gran detalle es un hack. La protección es inconsistente e incompleta, y la implementación podría ser complicada y, por lo menos, propensa a errores. Esto es importante porque, si bien puede ser "mejor que nada", no es "mejor que la alternativa"; Realmente puedes tener una buena seguridad, pero no es así.
Todo esto es un intento de actualizar las disposiciones de seguridad críticas en un sistema donde no fue diseñado para encajar. Y ese es realmente el núcleo del problema: el sistema fue creado para resolver problemas poco comunes o inexistentes, mientras ignoraba problemas reales, serios y apremiantes. Así que estamos tomando un sistema que estaba mal diseñado para comenzar e intentamos parchearlo para que sea de "calidad profesional". Es como tomar planos de rascacielos dibujados por un mecánico de automóviles e intentar arreglarlos para hacer algo que realmente podría construirse. El enfoque más práctico y efectivo es comenzar de cero.
¿Podríamos construir una alternativa segura?
Por supuesto que podríamos. Pero la clave para hacerlo es mirar primero su caso de uso principal y modelo de amenaza, y construir el sistema en consecuencia. Por ejemplo, SQRL fue diseñado para que toda la autenticación se realice en su teléfono celular. Podría adaptar la solución para permitir la integración del navegador, pero todas las características y decisiones de diseño se basaron en la suposición de que su teléfono celular es su identidad, por lo que la protección contra el phishing es tan difícil.
Diseñar un sistema para abordar todos los escenarios de ataque más probables es realmente simple. Todos los componentes necesarios existen, y todos los problemas ya han sido resueltos. No voy a entrar en detalles aquí, ya que este no es el lugar para hacerlo, pero apostaría a que si le preguntaras a una docena de expertos reales en seguridad e identidad, todos tendrían aproximadamente el mismo diseño.