¿Existe algún riesgo de seguridad si se filtra la base de datos con identificadores clave para dispositivos U2F?

Question

¿Existe algún riesgo de seguridad si se filtra la base de datos con identificadores clave para dispositivos U2F?

#1 de darco (1 votos)
#2 de AleSil (0 votos)

4

¿Existe algún riesgo si se filtra una base de datos de identificadores de claves de dispositivos U2F?

El registro de una clave funciona mediante:

Enviar solicitud de inscripción con "AppID" a dispositivo U2F.
El dispositivo U2F responde con "Key Handle, Public Key".

Trabajos de autenticación de:
Envíe la solicitud de autenticación con "AppID, Key Handle, Challenge" al dispositivo U2F. El dispositivo U2F firma esto y devuelve "Desafío firmado" al servidor.

El "identificador de clave" es un elemento opaco, que puede ser una clave privada encriptada, que está cifrada por el controlador de la tarjeta inteligente U2F, pero también puede ser información que solo se puede usar para que el controlador de la tarjeta inteligente regenere la clave privada , como una semilla que se coloca en un RNG determinista que es único para ese dispositivo U2F, una rutina de generación HMAC (Yubico U2F usa esto), o podría ser simplemente una identificación que apunta al almacenamiento interno en la clave U2F, pero eso limitaría la cantidad de sitios web en los que se puede registrar la clave U2F.

De acuerdo con el estándar, el usuario debe ser autenticado por nombre de usuario y contraseña antes de iniciar la autenticación U2F.

Pero digamos que omitimos la contraseña completamente, y en su lugar permitimos que el usuario ingrese su nombre de usuario, luego son llevados a la autenticación U2F y, voilá, están en.

Sin embargo, esto significaría que un usuario malintencionado podría enumerar todos los manejadores de claves, por lo que perdería todos los manejadores de claves en la base de datos.

¿Sería un riesgo para la seguridad el manejo de llaves con fugas? Parece que no debería ser así, pero como los manejadores de claves podrían contener claves privadas encriptadas, podrían ser (?). Un identificador de clave no sería utilizable por un sitio que no sea su AppID designado, ya que el dispositivo U2F rechazaría cualquier intento de autenticación que use un identificador de clave "robado". Sin embargo, esto lo impone el software / navegador cliente, ya que un software / navegador cliente malicioso podría simplemente falsificar el ID de aplicación.

authentication token u2f

pregunta sebastian nielsen 10.01.2015 - 02:09

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication token u2f

¿Cuál es la mejor manera de asegurar las respuestas en una aplicación web de una sola página después de cerrar la sesión? Herramientas para demostrar NO almacenamiento de datos de titulares de tarjetas

score 1 · Answer 1

Conclusión: Si por "riesgo" te refieres al riesgo de exponer tu servicio a la posibilidad de un ataque remoto, entonces no, no hay ningún riesgo adicional siempre que los tokens U2F FIDO se han implementado correctamente.

Sin embargo, el acceso a esta información permite que alguien con acceso físico (a través de NFC, por ejemplo) al token confirme fácilmente si un token determinado está asociado a una cuenta específica o no. Por ejemplo, si sospecho una asociación entre una persona específica (que usa un token NFC U2F, como un NEO de Yubikey) y un usuario en su sitio web, entonces podría verificar fácilmente esta sospecha sin su conocimiento si puedo acercarme lo suficiente físicamente. a su ficha.

Diferentes tokens también pueden tener diferentes longitudes del identificador de clave. Si el usuario utiliza un token con una longitud de identificador de clave inusual, este puede ser un método para ayudar a descartar modelos de token.

Si resulta que hay una debilidad en la implementación de FIDO U2F en el token que está utilizando un usuario, existe la posibilidad de que se aproveche, pero en ese caso, la implementación del token es probablemente el problema más grande.

En última instancia, creo que la decisión de hacer algo como esto depende de sus requisitos de seguridad. ¿Cuáles son las implicaciones de que alguien asocie una de sus cuentas a un token / persona específico?

También tenga en cuenta que eliminar el requisito de contraseña lo reduce a la autenticación de un solo factor.

score 0 · Answer 2

Sí, los pares U2F "AppParam / KeyHandle" con fugas deben considerarse como un riesgo para la seguridad. Según la preocupación de privacidad de FIDO: "la identificación de los dispositivos revelaría un identificador único para un dispositivo en orígenes no relacionados, lo que viola la privacidad del usuario". (c) Especificaciones FIDO. Por lo tanto, esta fuga permitirá al menos que un atacante pueda identificar el dispositivo en particular.

También tenga en cuenta que un malware en el host de Windows puede enumerar fácilmente 1000 pares (AppParam, KeyHandle) con un dispositivo U2F insertado sin la interacción del usuario. Una vez que se identifica el KeyHandle válido, un malware puede simular fácilmente alguna acción de UI y hacer que el usuario presione un botón en U2F para generar una firma. ¿Y ahora supongamos que se descubrirá una vulnerabilidad de 0 días en U2F que permita firmar cualquier compendio sin la interacción del usuario?

Y sí, tienes razón, KeyHandle es una clave privada cifrada de un par de claves ECDSA. Aquí está la declaración de los diseñadores de FIDO con respecto a KeyHandle: enlace

Se debe tener en cuenta que el ajuste de clave es una optimización opcional que los proveedores pueden Emplear, y que nuestra implementación es un enfoque. Las especificaciones FIDO U2F. Permitir que los fabricantes de dispositivos elijan cualquier enfoque para el ajuste de clave.

NuncahevistoningunaimplementacióndecódigoabiertodeldispositivoFIDOU2F,inclusoyubikodecidiómantenerestaconfidencialidad: enlace