Como de costumbre, tome todo lo relacionado con Steve Gibson con un montón de sal. Attrition.org obligatorio enlace .

Echemos un vistazo a la descripción de Gibson de su protocolo.

• El código QR que aparece cerca del inicio de sesión El mensaje contiene la URL del servicio de autenticación del sitio. La URL incluye un número aleatorio largo generado de forma segura para que cada presentación de la página de inicio de sesión muestre un código QR diferente. (En los círculos criptográficos, este número aleatorio largo se conoce como “nonce”).

• La aplicación de autenticación SQRL del teléfono inteligente codifica criptográficamente el nombre de dominio del sitio con la clave del usuario. «s clave maestra para producir un par de claves públicas específicas del sitio.

• La aplicación firma criptográficamente toda la URL contenida en el código QR utilizando la clave privada específica del sitio. Dado que la URL incluye un número aleatorio largo y seguro (el nonce), la firma es única para ese sitio y código QR.

• La aplicación emite una consulta POST HTTPS segura al QR URL del código, que es el servicio de autenticación del sitio. El POST proporciona la clave pública específica del sitio y la firma criptográfica correspondiente de la URL del código QR.

• El sitio web de autenticación recibe y reconoce la consulta POST devolviendo un HTTP estándar «200 OK» sin otro contenido. La aplicación SQRL reconoce el envío exitoso del código QR firmado por el usuario.

• El sitio de autenticación tiene la URL que contiene el nonce que regresó de la página de inicio de sesión a través de los teléfono inteligente. También tiene una firma criptográfica de esa URL y la clave pública específica del sitio del usuario. Utiliza la clave pública para verificar que la firma sea válida para la URL. Esto confirma que el usuario que produjo la firma utilizó la clave privada correspondiente a la clave pública. Después de verificar la firma, el sitio de autenticación reconoce al usuario ahora autenticado por su clave pública específica del sitio.

El Lo más importante que me llama la atención es el uso de una » clave maestra » por parte del usuario. Si leo el protocolo correctamente, esa única clave maestra controla toda la identidad en línea del usuario …

Presumiblemente, esta clave maestra se almacena en el teléfono del usuario en una base de datos de la aplicación. Lo que abre un enorme vector de ataque en forma de malware diseñado específicamente para robar la clave maestra.

Así que comparemos la diferencia entre lo que sucede cuando una contraseña se ve comprometida y lo que sucede cuando la clave maestra se ve comprometida. Suponiendo que está siguiendo las buenas prácticas de contraseñas de contraseñas largas, únicas y altamente aleatorias almacenadas en un administrador de contraseñas, todo lo que tiene que hacer es cambiar una sola contraseña si se ve comprometida. ¿Qué sucede si su clave maestra se ve comprometida? tendrá que obtener de alguna manera todos los sitios con los que se autenticó para reconocer que su clave maestra ha sido comprometida. El único problema es que no tiene ningún otro medio para autenticarse en el sitio, como nombres de usuario o direcciones de correo electrónico, ¿cómo sabrá el sitio que, de hecho, es usted quien está intentando revocar la clave maestra?

Como todo lo que sale de Gibson, este esquema SRQL es muy defectuoso y no ofrece beneficios sobre los convencionales métodos.

Comme nts

• » Si ‘ sigue las buenas prácticas de contraseñas » es una gran advertencia, y la mayoría de los internautas no ‘ no lo hacen.Parte de la promesa de SQRL ‘ es reducir la necesidad de ‘ de los usuarios de mantenerse al tanto de las mejores prácticas. Además, la especificación SQRL exigirá que la clave maestra se almacene encriptada con una contraseña maestra y será imposible utilizar la fuerza bruta (sintonizada para tomar ~ 60 segundos por intento). Obtener la contraseña a menudo no será trivial, ya que SQRL promueve la autenticación fuera de banda (es decir, registrar una máquina pirateada ‘ t siempre te ayudará). Entonces, si bien las consecuencias de un compromiso total son altas, la probabilidad de compromiso es algo baja.
• SQRL aún puede tener fallas que deben abordarse, pero afirma que resuelve una serie de problemas que se encuentran en los enfoques existentes para la autenticación, y cualquier crítica a SQRL que lo afirme » no ofrece beneficios » debe incluir refutaciones de estas afirmaciones en lugar de esperar que la afirmación sea aceptada ciegamente.
• > Como cualquier cosa que surja de Gibson , este esquema SRQL tiene muchos defectos y no ofrece beneficios sobre los métodos convencionales. — Esto no ‘ parece ayudar a responder la pregunta, y realmente siento que tienes problemas con la tecnología debido a quién la inventó. Algunos de los puntos que mencionó como fallas en realidad se tratan en la » spec «. Por ejemplo, el propio SQRL no ‘ t menciona cómo se almacena la clave maestra, pero los comentarios de Steve Gibson ‘ al respecto son que un el cliente, por ejemplo, lo encriptaría con una contraseña maestra usando un scrypt que demora en promedio 60 segundos en ejecutarse.
• Gibson aborda explícitamente la protección de la clave maestra.
• Mantenga presionada una segundo. Usted equipara el robo de su clave maestra SQRL con el robo de una de sus claves de LastPass. ¿No sería ‘ una mejor analogía equipararlo con el robo de toda su base de datos de contraseñas LastPass descifrada ?

En general, el protocolo no parece aumentar la seguridad sobre la tecnología existente. Si está buscando la mejor manera de proteger su identidad en línea, esta es sin duda no . Pero repasemos los pros y los contras:

Ventajas

Es imposible » compartir » una contraseña en el sentido estricto de que un sitio web malintencionado no puede utilizar la autenticación proporcionada a un sitio para iniciar sesión en otro sitio.

Un ataque de fuerza bruta contra el token de autenticación es no es factible.

Las credenciales no se almacenan en su computadora. Esto lo protege contra un pequeño subconjunto de Ataques dirigidos a estaciones de trabajo. Específicamente, está protegido contra ataques que roban su contraseña de su computadora. Sin embargo, no está protegido contra ningún tipo de secuestro de sesión o ataques de toma de control del navegador, y ahora también es susceptible a ataques relacionados con el teléfono. Más sobre eso más adelante.

Desventajas

Esta técnica es peligrosamente susceptible a los ataques MITM y la ingeniería social. Probablemente más que cualquier otro esquema de autenticación en uso, incluidas las contraseñas. El paso de autenticación y el paso de inicio de sesión están intrínsecamente desconectados en el sentido de que el teléfono se autenticará correctamente contra cualquier código QR presentado, sin importar cómo o dónde se presente al usuario.

Entonces, por ejemplo, Un sitio de phishing puede mostrar un código QR de inicio de sesión auténtico que registra al atacante en lugar del usuario. Gibson confía en que los usuarios verán el nombre del banco, la tienda o el sitio en la aplicación del teléfono durante la autenticación y, por lo tanto, ejercerán la vigilancia suficiente para frustrar los ataques. La historia sugiere que esto es poco probable, y la expectativa más razonable es que ver el nombre correcto en la aplicación tranquilizará falsamente al usuario haciéndole pensar que el sitio es legítimo porque pudo activar la solicitud de inicio de sesión familiar en el teléfono. La precaución que ya se ha hecho en la cabeza de los usuarios con respecto a la seguridad de las contraseñas no se traduce necesariamente en nuevas técnicas de autenticación como esta, que es lo que hace que esta aplicación sea inherentemente menos resistente a la ingeniería social.

Esta técnica combina la autenticación y la identidad en un objeto físico que con frecuencia se pierde o es robado. En este sentido, » s más un pasaporte que una contraseña. Cualquiera que esté en posesión de su teléfono de repente está exclusivamente en posesión de su identidad: no solo el atacante puede hacerse pasar por usted, sino sin una segunda copia en un segundo teléfono ( improbable), ahora ha perdido la capacidad de identificarse.Las claves de autenticación no se pueden revocar, por lo que sin una recuperación fuera de banda de todos y cada uno de los sitios, no puede recuperar su identidad. E incluso si existe una recuperación fuera de banda, cuando se enfrenta a dos usuarios, uno que posee la identidad y otro que no, puede resultar difícil ver por qué el operador del sitio debe confiar en usted.

Esta técnica combina todos sus tokens de autenticación en una sola clave a menos que cree manualmente otros. Esto hace que tu clave sea un objetivo extra jugoso para los atacantes. Además, la clave se almacena en su teléfono, dispositivos que normalmente han tenido una seguridad interna ridículamente porosa. La combinación de objetivos inusualmente jugosos con una seguridad deficiente no lo hace seguro.

Alternativas

El aspecto más problemático de este esquema es lo poco que se compara con las alternativas disponibles.

La opción más segura aceptada universalmente en la actualidad es lastpass, keepass y otros sistemas de contraseñas integrados en el navegador. En particular, el cifrado del lado del cliente alivia la necesidad de confiar en terceros. Y lo que es más importante, la integración del navegador hace que el phishing sea prácticamente imposible . LastPass o KeePass solo completarán la contraseña si se proporciona desde el dominio correcto, lo que significa que si se le presenta un sitio malicioso, el usuario no tendrá acceso a su contraseña.

Además, LastPass agregó recientemente una función lo que incita a los usuarios a cambiar contraseñas que no son únicas a nivel mundial. Esto ayuda a prevenir la reutilización de contraseñas, lo que significa que el beneficio principal de la técnica de Gibson se puede obtener fácilmente utilizando esta herramienta hoy en día en sitios existentes, sin la inseguridad adicional que implica su esquema.

Los esquemas de autenticación de segundo factor existentes que utilizan teléfonos o dispositivos similares ayudan a proteger los inicios de sesión de los usuarios en la actualidad ya lo hacen de tal manera que no lo hacen inmediatamente vulnerable al robo de identidad si su dispositivo es robado. La seguridad de la autenticación de dos factores radica en el hecho de que ni el dispositivo ni la contraseña pueden usarse si se roban sin el otro. La técnica de Gibson es en gran medida resistente a ser incluida en un esquema de dos factores, lo que hace que este nivel de protección ción no disponible.

TL; DR:

La técnica de autenticación de Gibson no genera un beneficio suficiente para superar los costos de seguridad adicionales que también impone. Estos costos son una parte fundamental del esquema en sí y probablemente no se pueden resolver sin descartar todo el diseño.

Se podría argumentar que es mejor que nada, pero no se puede argumentar que es mejor que todo lo que ya tenemos.

Actualizaciones de Gibson

Gibson anunció recientemente una protección adicional contra el phishing porque ha sido una gran crítica. Su protección es la siguiente: si NO está utilizando los códigos QR, el teléfono celular, etc., y en su lugar tiene un agente de autenticación en su sistema (en el navegador, por ejemplo), entonces el servidor puede verificar que la autenticación La respuesta proviene de la misma IP que la solicitud de autenticación. Esto está bien, pero el propósito de este protocolo es transferir su identidad a su teléfono celular. Si la única forma segura de usar el protocolo es no usar su núcleo función, entonces quizás deberíamos reconsiderar lo que estamos tratando de lograr.

Teóricamente, podría continuar usando su teléfono celular si (y solo si) su teléfono celular supiera que estaba usando la misma IP que su computadora. Lo cual, por supuesto, no puede saber porque no conoce la dirección IP de su computadora.

Una solución mejor

Como se indicó anteriormente, si la medida de autenticación está en su navegador, , entonces todo el problema de phishing se resuelve de inmediato sin ningún esfuerzo ni verificación por parte de Incluso el usuario menos capaz «no puede ser engañado para que se autentique en el sitio equivocado porque el token de autenticación del sitio está asociado con el nombre de dominio, y el navegador ganó» t permitir la autenticación en el dominio incorrecto. Esta es una técnica que ya se utiliza en la actualidad, es completamente automática y no requiere la cooperación del sitio ni ninguna inteligencia por parte del usuario.

Este método puede fortalecerse requiriendo un segundo factor de autenticación (como una tecla variable en el tiempo en un teléfono celular) que, nuevamente, ya está disponible y en uso hoy, lo que lo protege (más notablemente) contra errores por parte del sitio o la empresa de destino.

En cuanto a las preocupaciones sobre la vulnerabilidad de la autenticación del lado del navegador a los ataques de la estación de trabajo del cliente: si bien es cierto, también es cierto que si su navegador está comprometido, entonces no el uso de ese navegador es seguro , independientemente del mecanismo de autenticación que utilice.Los autores de malware pueden (y ya lo hacen) esperar a que se autentique por su cuenta utilizando su técnica súper segura y luego enviar silenciosamente el tráfico necesario a » propio » tu cuenta, todo sin que veas nada incorrecto. Ni SQRL ni ningún otro sistema de autenticación pueden proteger al usuario de un navegador comprometido, al igual que las cerraduras de las puertas pueden protegerlo de un incendio en la casa. Comprar cerraduras ignífugas no es una solución.

Dónde sigue

Si «está buscando una garantía absoluta de protección contra la suplantación , luego mire el token Fido U2F. Este estándar brilla donde SQRL se queda corto, y le brinda inmunidad garantizada a los ataques MITM (por ejemplo, phishing). Lo hace autenticando no solo al usuario, sino también al canal, por lo que Se garantiza que (a) su cuenta no puede ser autenticada sin el token, y también (b) su token solo se puede usar para autenticar una conexión a la máquina a la que está conectado. Consulte esta respuesta para obtener más información.

Comentarios

• Acerca del primer punto : por lo que tengo entendido, se pensó en esto y una opción es permitir que el sitio web en el que se está autenticando sea responsable de la redirección. Por lo tanto, al iniciar sesión, se le redirige a la página del ‘ del banco real, no al atacante. Sobre el segundo punto, lo mismo sucede hoy con los usuarios de herramientas como LastPass. A menos que configure algún mecanismo de protección (PIN, por ejemplo), todas sus contraseñas también serán robadas. ¿Por qué ‘ no puede aplicarse lo mismo a SQRL? Además, según tengo entendido por las especificaciones, el usuario puede hacer una copia de seguridad de su identidad incluso en papel (como un código QR).
• Y sobre el tercer punto: lo mismo sucede con la mayoría de los usuarios que no ‘ t use un administrador de contraseñas, simplemente usando un solo nombre de usuario / contraseña en varios sitios web. O, con usuarios de administradores de contraseñas, cuya » identidad » se distribuye en varios sitios web, pero se almacena en una sola ubicación (LastPass ‘ servidores, base de datos 1Password, etc.). Por lo tanto, ‘ no es realmente un defecto de SQRL. Con todo, cuanto más leo sobre SQRL, más veo los beneficios en comparación con las alternativas actuales. Diga lo que dice sobre Steve Gibson, pero SQRL realmente me parece una buena alternativa.
• » La advertencia ya se ha hecho presente en la cabeza de usuarios con respecto a la seguridad de las contraseñas no necesariamente se traduce en nuevas técnicas de autenticación como esta. . . » Este es un punto excelente, y el marketing ya ha perdido la batalla. Los códigos QR se consideran una forma fácil de hacer las cosas, no como un vector de ataque potencial. Los pares de nombre de usuario / contraseña al menos se usaron PRIMERO como mecanismo de autenticación, no como herramienta de marketing.
• @jpkrohling: Con respecto a los administradores de contraseñas, supongo que la mayoría de los usuarios de dicho software NO almacenan su contraseña maestra en su dispositivo móvil, precisamente porque son conscientes de lo peligroso que es. Tengo una copia física de mi contraseña maestra en un lugar seguro, pero no copias electrónicas. Los ataques que otorgarían acceso a mi contraseña maestra son diferentes de los que comprometerían la contraseña de un sitio y son mucho menos probables. (Principalmente porque atacar mi base de datos de contraseñas implicaría atacarme personalmente, en lugar de un gran sitio comprometido).
• @jpkrohling Ni LastPass ni KeePass almacenan una contraseña maestra en ningún lugar. Se ‘ se usa para desbloquear su base de datos de contraseñas, pero no se ‘ t almacenado. Esto es fundamentalmente diferente de tener una sola clave que, en sí misma, se usa en todas partes.

SQRL ciertamente no está exento de fallas, pero es ciertamente superior a la mayoría de las soluciones de autenticación primarias ampliamente utilizadas en la web hoy en día en términos de seguridad y (y esto es importante) usabilidad. Permítame explicarlo.

Conceptos erróneos

Primero, permítanme aclarar algunos de los conceptos erróneos presentes en algunas de las otras respuestas sobre esta pregunta. Muchas de estas respuestas están desactualizadas y se escribieron antes de los cambios en la documentación de SQRL que abordan los problemas presentados en ellos, mientras que otros parecen poner un énfasis indebido en las fallas en SQRL que también están presentes en muchas otras soluciones de autenticación existentes ampliamente utilizadas, mientras ignoran sus beneficios. Así que aclaremos algunos conceptos erróneos aquí. ¿Nosotros?

Mito: SQRL requiere escanear códigos QR para funcionar

Esto simplemente no es cierto. Los códigos QR son una conveniencia lo que hace que SQRL sea más fácil de usar en computadoras en las que el usuario no ha configurado el software cliente SQRL. El sitio web de SQRL establece lo siguiente:

Tres formas de hacerlo…teléfono inteligente opcional:

Aunque la inspiración original para el desarrollo de este sistema fue un teléfono inteligente que escaneaba un código QR en la página de inicio de sesión de un sitio web, una pequeña adición a ese modelo permite dos modos de operación más importantes: Simplemente Haga que la imagen del código QR también sea un enlace en el que se puede hacer clic a la misma URL que está codificada en el código QR. Esto proporciona tres formas de iniciar sesión:

• Escanee el código con un teléfono inteligente: Con el modelo descrito anteriormente, el teléfono inteligente de un usuario escanea el código QR que aparece en la página de inicio de sesión de un sitio web y el usuario inicia sesión en ese sitio.
• TAP EL CÓDIGO en un teléfono inteligente: Para iniciar sesión en un sitio web EN el teléfono inteligente, cuando el código SQRL visual también es un enlace de estilo URL (usando sqrl: // como esquema) el La aplicación SQRL instalada en el teléfono inteligente recibirá ese enlace e iniciará la sesión del usuario en el sitio de forma segura en el teléfono.
• Haga clic en el código en la pantalla de una computadora de escritorio o portátil : Para usar el sistema SQRL en cualquier sistema de escritorio o portátil, se instalaría una aplicación SQRL de escritorio y se registraría para recibir enlaces sqrl: //. (Esto es similar a la forma en que un programa de correo electrónico se registra para recibir enlaces mailto:). Esto permite que los usuarios utilicen en su escritorio la misma solución que utilizan en sus teléfonos inteligentes. Cuando cualquier sitio web ofrece un código SQRL, el usuario simplemente hace clic en el código con el cursor del mouse y la aplicación SQRL instalada localmente aparecerá, le pedirá su contraseña SQRL, confirme el dominio y luego inicie sesión.

Mito: La clave maestra SQRL se almacena completamente sin cifrar y sin protección en su teléfono

No estoy seguro de por qué algunas personas hicieron esto suposición, ya que me parece obvio que este no sería el caso. La clave maestra SQRL está protegida de la misma manera que protegería una base de datos de contraseñas: con una contraseña maestra segura. Robar el teléfono de un usuario no le daría acceso automáticamente a su identidad en línea a menos que también tuviera su contraseña maestra. Se explican más detalles sobre la administración de claves en la página sobre Cliente SQRL- Side Key Management en el sitio web de SQRL.

Mito: Si le roban su clave maestra, no puede cambiar sus credenciales de inicio de sesión

Esto también es falso. SQRL proporciona una forma integrada de permitir que el titular genuino de la cuenta actualice sus credenciales de inicio de sesión en el caso de una clave comprometida. Esta función se conoce como Bloqueo de identidad:

«Identity Lock» evita el cambio de identidad & permite la recuperación: Esto es también lo suficientemente significativo como para merecer su propia página de descripción detallada: “ El protocolo de bloqueo de identidad ” (página 4 en el bloque de enlaces en la parte inferior de esta página). La identidad del usuario se ha establecido con un servidor web, el SQRL c lient es incapaz de cambiar esa identidad. Esto significa que si sucedió lo peor y se usó una contraseña muy débil y fácil de adivinar, o si se pirateó el teléfono o el escritorio de un usuario para obtener su clave maestra de identidad y contraseña, ningún tercero malintencionado puede cambiar la identidad en línea del usuario para bloquear sus propias cuentas en línea. Y, además, al cargar una «Clave de desbloqueo de identidad» normalmente fuera de línea, el verdadero propietario de su identidad puede retirarse y reemplazar su identidad en línea perdida o robada para esencialmente recuperarla. de cualquier atacante, lo que inutiliza su identidad anterior.

Plausible: SQRL es más vulnerable al phishing que soluciones de autenticación existentes

Bien, esto es en realidad parcialmente cierto. Cuando se usa SQRL escaneando un código QR, hay muy poca protección contra el phishing. A menos que el usuario tenga cuidado de asegurarse de que el sitio web que se muestra en la barra de URL de su navegador sea el mismo que el que muestra la aplicación Cliente SQRL, podría estar autorizando una sesión de inicio de sesión para el atacante. Esto es aún mejor que las contraseñas, donde Le darían al phisher acceso permanente a su cuenta (y cualquier otra cuenta que tenga en otro lugar y que comparta la misma contraseña) hasta que cambie su contraseña, pero no tan bien como otras soluciones que se integran con el navegador del usuario, como las claves U2F. , WebAuthn, certificados de cliente y (bajo ciertas condiciones) administradores de contraseñas.

Sin embargo, cuando «estás usando un cliente SQRL en el mismo dispositivo con el que estás iniciando sesión, SQRL tiene algunas protecciones contra phishing en su lugar. Estas protecciones se explican en el sitio web de SQRL, en la sección sobre Cómo SQRL puede frustrar los ataques de phishing .También existe la posibilidad de integrar SQRL con navegadores (posiblemente a través de complementos) para brindar una protección mucho más sólida contra ataques de phishing; a la par con soluciones como WebAuthn y certificados de cliente.

En general, clasifiqué a SQRL en aproximadamente al mismo nivel que los administradores de contraseñas para la protección contra el phishing. Tiene el potencial de brindar una protección sólida contra el phishing cuando se instala en el mismo dispositivo en el que el usuario está iniciando sesión, pero brinda una protección mínima cuando se instala en un dispositivo diferente.

Comparación con alternativas

Ahora comparemos SQRL con las soluciones de autenticación de uso generalizado existentes.

Contraseñas

SQRL es muy superior a las contraseñas de muchas formas. No solo es más conveniente de usar una vez configuradas ya que los usuarios no tienen que preocuparse por recordar o volver a escribir varias contraseñas diferentes para cada sitio, sino que también protege contra la reutilización de contraseñas, contraseñas débiles, keylogging y, hasta cierto punto, phishing.

Desventajas SQRL ha comparado con las contraseñas es que es más difícil de implementar para los operadores de sitios web, no es tan ampliamente utilizado, requiere más tiempo para configurarlo inicialmente, requiere algo de esfuerzo para transferirlo a un nuevo dispositivo y proporciona un único punto de falla para todas las cuentas del usuario si la llave maestra es robada (aunque este último punto También es el caso de las contraseñas si un usuario usa la misma contraseña en cada sitio).

Administradores de contraseñas

En muchos sentidos, SQRL es muy similar a los administradores de contraseñas. Ambos proporcionan un único ancla de confianza centralizada que sirve como una especie de proxy de autenticación entre los usuarios y los servicios individuales. Sin embargo, hay un par de formas en las que SQRL es superior a los administradores de contraseñas.

La principal ventaja que creo que tiene SQRL sobre los administradores de contraseñas es que es más fácil y más seguro de usar en computadoras que no son de confianza o solo parcialmente confiables. Por ejemplo, supongamos que un usuario quiere iniciar sesión en un sitio web utilizando una computadora en una biblioteca pública. Con un administrador de contraseñas, tendría que acceder a la contraseña de ese sitio en su teléfono y volver a escribirla en la computadora manualmente, o descargar su administrador de contraseñas y base de datos de contraseñas en la computadora de la biblioteca, desbloquee la base de datos con su contraseña maestra, luego inicie sesión. El primer escenario es inconveniente para el usuario y expone la contraseña de texto sin formato del usuario para ese sitio a la computadora que no es de confianza (y a cualquier malware en la computadora que no es de confianza, incluidos los keyloggers). El segundo escenario es aún peor, ya que es inconveniente y expone la base de datos de contraseñas completa y descifrada del usuario y la contraseña maestra a la computadora que no es de confianza. Con SQRL, el usuario solo tendría que escanear un código QR en la pantalla de la computadora que no es de confianza, lo cual es mucho más conveniente para el usuario, y solo expone una única sesión de inicio de sesión (sin credenciales reutilizables como una contraseña) a la computadora que no es de confianza .

Otra ventaja que tiene SQRL sobre los administradores de contraseñas es que es más fácil recuperarse del peor de los casos: el robo de la base de datos de contraseñas / clave maestra del usuario. Con un administrador de contraseñas no sólo tiene que cambiar su contraseña en cada sitio, también tendrá que preocuparse de que el atacante cambie sus contraseñas (posiblemente bloquee su cuenta). El atacante también tiene la ventaja de poseer una lista de todos los sitios que tiene cuenta, lo que hace que explotar el robo de una base de datos de contraseñas sea mucho más fácil. Con SQRL, el robo de su clave maestra sigue siendo una situación terrible, pero el atacante no tiene una lista de los sitios en los que tiene una cuenta (en su lugar, tiene que adivinar ) y no puede cambiar su contraseña para bloquearlo de su cuenta. Una vez que cargue su clave de desbloqueo de identidad, también es un poco más conveniente cambiar sus credenciales de inicio de sesión en cada sitio, ya que el cliente SQRL tiene la capacidad de hacerlo automáticamente para cada sitio que visite al iniciar sesión. (No es necesario ir a través de cualquier formulario de «cambio de contraseña».)

Finalmente, creo que SQRL tiene una ventaja pequeña pero importante sobre los administradores de contraseñas en lo que respecta a su objetivo de reemplazar las contraseñas por completo, y es que los sitios tienen la opción de hacer cumplir uso de SQRL sobre contraseñas tradicionales. Siempre que los usuarios aún tengan la opción de seguridad deficiente, reutilizar la misma contraseña en todos los sitios, eso es algo que aún sucederá. Si SQRL comienza a obtener una adopción generalizada, los sitios pueden comenzar a eliminar gradualmente el uso de contraseñas. Eso no se puede hacer con los administradores de contraseñas, ya que dependen del uso de contraseñas para funcionar.

En términos de desventajas, en realidad no puedo pensar en una situación en la que SQRL necesariamente sería peor que los administradores de contraseñas en términos de seguridad. La principal desventaja que tiene SQRL es que requiere el apoyo de los operadores de sitios web, mientras que los administradores de contraseñas no requieren un apoyo especial de los servicios existentes. Esto significa que puede comenzar a usar administradores de contraseñas ahora mismo, pero SQRL tendrá que esperar hasta que los sitios lo implementen antes de poder usarlo. Esta es una barrera importante para la adopción.

Certificados de cliente

La principal ventaja que tiene SQRL sobre los certificados de cliente es la conveniencia. Los certificados de cliente son actualmente complicados de configurar, difíciles de transferir entre computadoras y tienen problemas de privacidad cuando se usa el mismo certificado en diferentes sitios. Si bien, en teoría, podríamos construir un sistema utilizando certificados de cliente que resolverían estos problemas, también existiría el problema de una mala integración con las interfaces de usuario del sitio web y los servidores web, que son problemas más difíciles de resolver. No entraré en demasiados detalles aquí, ya que ya hay un excelente artículo sobre los problemas de usabilidad de los certificados de cliente en Browserauth.net.

En términos de seguridad, los certificados de cliente tienen la desventaja de requerir la participación de una CA. Esto es (potencialmente) caro y requiere confiar en la CA de terceros. Además, si opta por ignorar las CA y, en su lugar, autofirma sus certificados, tendrá que solucionar el problema de la revocación de certificados. Los certificados de cliente también tienen los mismos problemas de seguridad y conveniencia que los administradores de contraseñas cuando los usuarios desean iniciar sesión en una computadora que no es de confianza; tienen que transferir su certificado a la computadora que no es de confianza, lo cual es inconveniente y potencialmente expone su identidad maestra a malware en esa computadora.

En resumen, hasta que alguien encuentre una solución mejor y fácil de usar usando certificados de cliente que resuelven (al menos la mayoría de) estos problemas, no creo que los certificados de cliente sean un competidor serio de SQRL (o, para el caso, de contraseñas).

Autenticación de 2 factores

Pensé en mencionar esto: SQRL y la autenticación de 2 factores no se excluyen mutuamente. SQRL es un reemplazo del primer factor en 2FA: contraseñas. Otras medidas adicionales como códigos OTP o claves FIDO U2F aún se pueden usar con SQRL.

WebAuthn

Ahora aquí donde las cosas se ponen interesantes. WebAuthn es un nuevo estándar (bueno, más reciente que SQRL) W3C diseñado para proporcionar una API estándar que los sitios web pueden usar para autenticar a los usuarios con claves públicas en la Web. Al igual que SQRL, admite el uso del teléfono del usuario para autenticar una sesión de inicio de sesión en un dispositivo externo , además de algunos otros métodos de autenticación (como las claves de seguridad de segundo factor) .

Aquí es donde SQRL finalmente encuentra su pareja, al menos desde una perspectiva de seguridad. WebAuthn no solo proporciona las mismas protecciones contra la reutilización de contraseñas, contraseñas débiles y keylogging que SQRL, sino que también brinda una protección aún más fuerte contra el phishing al integrarse con el navegador del usuario incluso al autorizar un inicio de sesión. sesión para una PC en la que el usuario no ha configurado previamente el software de cliente del autenticador. Esto es posible porque en esa situación WebAuthn se comunica con el navegador del usuario directamente usando protocolos de comunicación bidireccionales como Blutooth o NFC en lugar de comunicarse con el sitio web que el usuario está usando a través de un código QR unidireccional.

Desde la perspectiva de la usabilidad, las cosas son un poco más complicadas. Al menos en la superficie, WebAuthn gana de nuevo. Porque es un estándar W3C que ya tiene implementaciones en varios navegadores , en teoría, los usuarios pueden comenzar a utilizar WebAuthn inmediatamente sin necesidad de instalar ningún software de terceros. Sin embargo, en la práctica, la mayoría de las implementaciones existentes de WebAuthn se centran en su uso como una forma de autenticación de segundo factor o como una forma de volver a autenticar a un usuario. que se registró previamente en el mismo dispositivo a través de un método de inicio de sesión diferente (generalmente una contraseña). Como factor de autenticación principal, WebAuthn todavía carece de implementaciones viables.

Otras consideraciones menores incluyen el hecho de que SQRL tiene una construcción Método t-in para rotar las claves de las cuentas en caso de robo de una clave maestra, mientras que WebAuthn se basa en sitios web para implementar su propio sistema para revocar claves, y el hecho de que WebAuthn requiere cierto hardware opcional (como Bluetooth o NFC) para para autenticarse en una máquina remota, mientras que SQRL puede funcionar en cualquier máquina con una pantalla que funcione.

En general, creo que es muy probable que WebAuthn eventualmente haga que SQRL quede obsoleto. Es posible que SQRL tenga un poco de espacio para respirar por ahora, pero WebAuthn tiene un respaldo mucho más fuerte de los proveedores de navegadores, operadores de sitios y otras organizaciones de terceros (como el W3C). Una vez que WebAuthn obtenga un par de implementaciones que permitan su uso como factor de autenticación principal, espero que comience a dominar la web muy rápidamente.

Advertencias

SQRL aún está en desarrollo activo, por lo que el material presentado en esta respuesta está sujeto a cambios. A medida que el desarrollo continúa, espero que se aborden algunas de las vulnerabilidades e incertidumbres en esta respuesta. La mayor parte de la discusión se está llevando a cabo actualmente en el grupo de noticias SQRL en grc.com.

SQRL es una solución conveniente al problema del nombre de usuario / contraseña paradox. (es decir, el compromiso entre conveniencia y seguridad) sin utilizar un . Proporciona una alternativa simple al modelo de autenticación más popular (nombre de usuario & contraseña), sin virtualmente comprometer la seguridad. Es prácticamente igual de seguro que cualquiera de los modelos de autenticación habituales que se utilizan en la actualidad, siempre que siga siendo consciente de la seguridad . Si utiliza SQRL, no significa que no pueda seguir las mejores prácticas de seguridad, como combinar esto con la autenticación multifactor para cuentas importantes.

Es importante no perder el punto de SQRL. SQRL en sí mismo no necesariamente proporciona mejor o peor seguridad. Si la computadora / teléfono se ve comprometido, o el usuario es engañado para siendo phishing, se trata de un ataque de canal lateral en lugar de una falla directa de la propia SQRL. Todos los métodos de autenticación convencionales tienen el problema de los ataques de canal lateral El pad único irrompible también es vulnerable a los ataques de canal lateral como el compromiso del pad en sí, o la mala seguridad o implementaciones circundantes.

Si escuchaste la propuesta original de la idea en Steve Gibson «s podcast , seguido de las Q & A «, muchas de las preocupaciones planteadas en este hilo de la pila han sido respondidas. Además, Steve mismo dijo que esta idea tan «simple» e «ingeniosa» (sus palabras) tendría que ser «examinada» y «martillada» por expertos en seguridad, ya que sólo el tiempo dirá si es una solución segura.

En conclusión, la mayoría de los argumentos en contra de SQRL caen fuera del dominio de SQRL en sí, y en cambio son problemas con humanos que practican una seguridad deficiente. SQRL no introduce una nueva clasificación de problemas que nuestros métodos de autenticación tradicionales ya no tienen.

SQRL es excelente si lo utilizan adecuadamente personas que se preocupan por la seguridad. Debe comprender que siempre existe un compromiso entre conveniencia y seguridad , y esta solución es probablemente la mejor equilibrio de los dos que he visto.

Comentarios

• Gracias Ansichart. Pero, ¿pueden ‘ t las soluciones de autenticación existentes simplemente retener características de seguridad iguales o superiores a las de SQRL y luego utilizar la automatización para aumentar la comodidad del usuario? ¿Qué propiedad fundamental de la conveniencia del usuario de SQRL ‘ es no debido a la automatización? Pregunto porque si un usuario tiene dos cajas negras que hacen lo mismo; una etiquetada como » Madura » y la otra etiquetada como » SQRL » y ambos pueden ser diseñados / automatizados tienen la misma interfaz / botones en el exterior de la caja – ¿Qué valor agregado proporciona SQRL?
• Resuelve el problema de la paradoja de la contraseña sin tener que utilizar un tercero.
• Ya veo. Por lo tanto, si alguien no ‘ no quiere el riesgo de terceros del inicio de sesión único y no ‘ no genera / almacena sus contraseñas con un administrador de contraseñas, SQRL puede intensificar. Pero si SQRL es una caja negra móvil que solicita una contraseña para desbloquear la clave maestra utilizada para regenerar / almacenar SQRLID y luego realizar el enlace de canal de retorno de la cookie / QR del cliente ‘ session_id con el servidor ‘ s registrado SQRLID para iniciar sesión – ¿cómo es esto una caja negra móvil diferente de un administrador de contraseñas móvil con inicio de sesión automático a través del mismo canal de retorno? o un complemento de certificado de cliente móvil de dos partes con inicio de sesión & de generación automática a través del mismo canal secundario?
• He realizado una edición importante de mi publicación original después de unas segundas consideraciones y una lectura más cercana a lo que otros han estado diciendo, ya que puedo haberlo exagerado. Supongo que tener el teléfono móvil como la clave central cambia el problema y haría más importante tener una seguridad más fuerte en su teléfono. Steve Gibson también menciona esto en el Q & A podcast.

Estoy de acuerdo con los otros comentarios hasta cierto punto, pero creo que hay algunos méritos:

Para habilitar SQRL para usted, debe crear su clave maestra y almacenarla en su teléfono . HECHO. A partir de ese segundo, podrá iniciar sesión en CUALQUIER sitio web que utilice «SQRL».Y eso sería un inicio de sesión anónimo, siempre que decida no proporcionar más información.

Eso es MUCHO más fácil que trabajar con su propio certificado; o crear cuentas de usuario explícitas (probablemente pidiéndole que proporcione una dirección de correo electrónico válida). Tal vez no usaría esa misma clave maestra para mis cuentas bancarias, de amazon, … pero especialmente para estas situaciones de «me gustaría publicar algo aquí» … perfecto. No más «por favor, informe a Google, Facebook o cualquier sitio que desee publicar aquí».

Comentarios

• I ‘ No estoy seguro de que este sea un punto válido; si ‘ va a permitir inicios de sesión anónimos, ¿por qué molestarse con un inicio de sesión en primer lugar? Un simple captcha sería suficiente para evitar el spam.
• Debido a que el inicio de sesión anón es USTED, simplemente se niega a proporcionar información sobre su identidad; nadie puede falsificarlo.
• Suena casi como un re-hash a medio hacer de Windows CardSpace.
• O un captcha, si está ingresando un usuario que nunca ha iniciado sesión antes.
• » Para habilitar SQRL para usted, debe crear su clave maestra y almacenarla en su teléfono. » En realidad, ‘ no necesita hacer eso, solo necesita algún software en su PC que pueda abrir URLs sqrl: //.

SQRL no proporciona mejoras innovadoras. Los códigos QR son un formato de código de barras óptico útil para la distribución de contenido corto, nada más.

Cualquier situación de «inicio de sesión automático» que SQRL esté tratando de resolver podría simplemente usar un certificado de cliente almacenado en el móvil.

Hipotéticamente, un código de barras QR en una página HTTPS podría devolver una versión encriptada o firmada por el servidor del certificado de cliente (o una credencial similar) como la conocía previamente el servidor, pero ¿por qué? ¿Para el vencimiento de la credencial? El sitio podría simplemente rechazar una credencial caducada directamente.

Entonces, el mayor problema de seguridad que tengo con esto el protocolo es: Reinventar la rueda cuadrada .

Update

Al leer nuevas respuestas y comentarios, me gustaría señalar lo fácil que es hacer algo similar a SQRL a través de automatización simple de tecnología madura existente :

1. El sitio web solicita cualquier CAPTCHA o verificación similar «Yo» ma humano. Una vez que el usuario ha cumplido (PUBLICADO), el sitio web devuelve un HTTP 403.7 - Client Certificate Required o un error 403 de vainilla.
2. Las páginas 403 personalizadas son lo suficientemente fáciles de configurar y pueden ser bastante bonitas y fáciles de usar. Incluso podría arrancar la funcionalidad requerida a continuación de una manera similar a las indicaciones de «Se requiere Adobe Reader» en muchos sitios web.
3. La página 403 personalizada incluye algunas marcas a las que reacciona un complemento de navegador personalizado. Llamemos a este complemento personalizado «compatible con S403L» en el espíritu de «cumplimiento de SQRL».
4. El complemento S403L genera un certificado de cliente estándar, que está protegido en el caché de certificados cifrado habitual del navegador (o un tercero). caché del partido si el cifrado del almacén de claves de su navegador apesta). El complemento crea una CSR estándar para el certificado del cliente y envía la CSR a la URL especificada en el marcado 403 (p.
5. El servidor compatible con S403L utiliza el session_id del usuario (recuperado de las cookies o la cadena de consulta) para crear continuidad con el Paso 1 y luego devuelve la CSR firmada por el servidor. La autenticación general del servidor aceptará cualquier certificado de cliente que haya sido firmado por el servidor (y por lo tanto cumplió con los criterios de registro exigidos en el Paso 1).
6. El complemento S403L almacena ese certificado de cliente firmado en la memoria caché del navegador. luego, el navegador estándar sin asistencia de complementos puede «iniciar sesión automáticamente» en el servidor en la forma estándar SSL / TLS hasta que el certificado caduque.

La naturaleza «móvil» y «visual» de SQRL es una especie de desvío, ya que no proporciona autenticación separada de dos factores y ahora necesita dos computadoras para navegar por Internet en lugar de una. A menos que apunte la cámara web USB de su escritorio a su propio monitor.

Las compensaciones entre contraseñas y certificados están bien definidas en la comunidad de seguridad: las contraseñas encajan en un cerebro humano; los certificados no encajan un cerebro humano ( generalmente ) pero puede tener entropía loca y buenas funciones de administración de PKI (vencimiento , revocación, extensiones de póliza, etc.). SQRL no encaja perfectamente en ninguno de los campos; y si se está desplazando hacia el campo más informático menos humano como parece ser, tiene años de desarrollo y análisis de seguridad para repetir las características X.509 existentes.

Comentarios

• > simplemente podría usar un certificado de cliente almacenado en el móvil.— excepto que esta tecnología existe desde hace años tanto en dispositivos móviles como en computadoras de escritorio, y ‘ no está tan extendida como uno desearía. Y a diferencia del certificado de cliente, SQRL no ‘ t requiere que demuestre su identidad real para crear una » SQRL Identity «. Si lo desea, puede crear tantas identidades como desee. Esto significa que la ventaja en comparación con los certificados de cliente es que tiene el anonimato del lado del protocolo de autenticación ‘.
• @jpkrohling Es un error común pensar que los certificados de cliente requerir divulgación de identidad para su uso. Ese es un requisito de las autoridades de firmas comerciales para utilizar sus cadenas de confianza intercambiables a nivel mundial. En la práctica, un certificado de cliente puede ser simplemente una CSR anónima creada por el cliente y firmada por un servidor específico, después de cumplir con los criterios que se deseen (CAPTCHA, cuenta anterior, etc). Los certificados también pueden tener una caducidad incorporada. Type 40-L Los códigos de barras QR pueden enviar / almacenar el certificado de cliente X.509 de 1KB si lo desea.
• Vale, cierto, mi error. Desde esta perspectiva, el cliente (aplicación móvil, por ejemplo), podría generar un certificado de cliente para cada sitio web que el usuario esté registrando. Esto suena más caro que el hash de cierta información, pero podría ser una solución interesante. En cualquier caso, todavía no ‘ estoy de acuerdo con sus afirmaciones de que SQRL es peor que inútil.
• Tal vez fui duro con esa redacción y la eliminaré. Pero ‘ no veo a SQRL como otra cosa que una forma más atractiva de distribuir las credenciales de cliente negociadas; y uno que no ha ‘ t resuelto algunos de los problemas sutiles que solucionan los esquemas de autenticación maduros. Un administrador de contraseñas es tedioso (no ‘ me molesto con la integración del navegador porque ‘ soy paranoico) pero sé que solo uno y yo sitio web comparte cada contraseña única en mi almacén de claves cifradas. No ‘ no tengo que preocuparme por los nuevos y sofisticados esquemas hash / auth, solo por la calidad del PRNG / TRNG que mi administrador de contraseñas usa para generar contraseñas.
• @LateralFractal ¿a quién le importa si ‘ es nuevo o no? SQRL permite una autenticación fácil de usar donde la primera parte no expone su secreto con la segunda parte o cualquier tercero que pueda haber comprometido la seguridad de la segunda parte ‘. Es ‘ un intento de resolver un problema del mundo real que, hasta ahora, nadie más ha podido resolver.

Me gustaría abordar la primera pregunta: «uno de los problemas que se me ocurren es si el lector de QR está comprometido, mostrar www.google.com en lugar de www.nsa-super-secret-place.gov/123 «:

La clave maestra se usa como semilla en HMAC junto con la dirección del sitio web (FQDN). Entonces, aunque el código QR puede codificar una URL completamente diferente, el protocolo NO revelará el código de autenticación que normalmente se enviaría a www.google.com (en el ejemplo).

En segundo lugar, muchos de los colaboradores se olvidan de los objetivos clave al desarrollar esta idea:

1. anonimato al no utilizar terceros
2. facilidad de uso
3. no es necesario escribir una credencial secreta en computadoras que no son de confianza

¡Creo que los protocolos los tratan en su totalidad!

Sin embargo, existen compromisos que en realidad provienen del primer objectjive. Si ningún tercero está involucrado en la autenticación, ¿cómo se pueden revocar sus datos de autenticación? Además, la seguridad de la clave maestra es una preocupación obvia. Imagino que esto estará bien protegido por futuros dispositivos móviles en un chip tipo HSM. Hasta entonces, la clave es solo un dispositivo móvil de pin de archivo, protegido por una contraseña, aunque PBDKF2 asegura que es muy lento para forzarlo realmente.

Comentarios

• Nuevamente, ¿qué ‘ hay de nuevo sobre esta idea? Me parece que es una variación primitiva del ahora desaparecido Windows CardSpace.
• Sí, tienes razón sobre CardSpace. Luego está U-Prove también propiedad de Microsoft. La pregunta es cómo usaría CardSpace o U-Prove en una computadora en la que no confía (cibercafé o computadora de amigos). Eso es lo que Steve agregó.
• Ah, está bien, eso ‘ es lo que me faltaba. Todavía estoy de acuerdo con @TerryChia en que este no es un motor de arranque sin un mecanismo de revocación para las claves de usuario.
• @Xander Hay hay un mecanismo de revocación para las claves de usuario. grc.com/sqrl/idlock.htm