Uso del UUID V4 para la autenticación

Los UUID generalmente no garantizan la imprevisibilidad ni ninguna propiedad de seguridad. Como dice RFC 4122 (sección 6):

  

No asuma que los UUID son difíciles de adivinar; no deben utilizarse como capacidades de seguridad (identificadores cuya mera posesión otorga acceso), por ejemplo. Una fuente de números aleatorios predecible exacerbará la situación.

Lo que necesita aquí es un generador de números aleatorios criptográficamente seguro . Algunas implementaciones de UUID se eliminan de dichos RNG, pero esa es una opción de implementación, no una garantía. El norma de la UIT dice explícitamente que el uso del número aleatorio criptográfico es < fuerte> recomendado , lo que claramente implica que no es un requisito (pág. 10):

  

Se recomienda encarecidamente el uso de números aleatorios de calidad criptográfica para reducir la probabilidad de valores repetidos.

Y resulta que algunas implementaciones UUID no son seguras. Por ejemplo, al menos algunas versiones del motor V8 Javascript de Google utilizan un PRNG no criptográfico para la generación aleatoria de UUID . El enlace describe cómo atacar tales UUID: con un par de líneas de código, un atacante que ve uno de esos UUID puede reconstruir el estado de PRNG cuando genera ese UUID, lo que les permite predecir todos los UUID posteriores.

Por lo tanto, no usaría los UUID como secretos criptográficos; me conectaría directamente con el RNG criptográfico, al menos para hacer evidente el intento del código.

El mayor problema es que sus usuarios no podrían recordar tales tokens; tendrían que almacenarlos en un lugar seguro, y usted no estaría brindando asistencia para hacerlo. La alternativa obvia pero realmente muy natural aquí es usar un sistema de autenticación de múltiples factores basado en las contraseñas y claves secretas, como TOTP . Por ejemplo, si crea una integración con Google Authenticator o Authy , sus usuarios obtienen el beneficio de las aplicaciones del lado del usuario de esos proveedores para almacenar y administrar la clave secreta compartida.

Simplemente estás describiendo un esquema en el que el UUID simplemente se convierte en una contraseña.

No hay nada especialmente seguro o inseguro al respecto, aparte de que ninguna persona podrá elegir una contraseña "débil", pero, por otro lado, la mitad de las personas va a almacenar su contraseña sin cifrar.

Realmente no veo por qué le harías esto a la gente. No vas a hacerte muy popular al negar a los aficionados la oportunidad de elegir una contraseña que puedan recordar, ni a los expertos la oportunidad de generar una que ellos mismos consideren segura.

También, personalmente, creo que las contraseñas de cuentas bancarias individuales valen mucho menos (considerando que los bancos han sido transferencias bancarias de 2 factores, al menos en Europa, desde hace más de 25 años con ID de transacción una vez) pads) que el control de dominio (casi no puedo arruinar el negocio de alguien mirando su cuenta bancaria a menos que planee usarlo para meterme con él en base a otra información, pero puedo arruinarlo fácilmente redirigiendo todo su correo electrónico a través de mis servidores al manipular el Registre MX de su dominio, y deje pasar selectivamente el correo del CEO y responda en su lugar. Ah, y saben, si tienen un negocio en línea, realmente abusan de su presencia en la web en la mayor medida posible.

Entonces:

  

Dado lo anterior, ¿sigue siendo una mala idea?

Sí, inventar nuevos esquemas de autenticación suele ser una mala idea.

  

¿Crees que esto es menos seguro que el nombre de usuario / pase?

Depende de sus clientes y, como es habitual, de su escenario de ataque.

  

¿Sería más seguro cerrar dos UUID juntos?

Llevaría a secuencias aleatorias más largas, así que sí, pero entonces, ¿por qué no usar una secuencia aleatoria más larga desde el principio?

Todo esto se siente como si no hubieras pensado en esto.