Herramientas de desarrollo · UUID generador
¿Es un UUID aleatorio seguro como restablecimiento de contraseña o token de sesión?
· Por qué es importante
uuid criptografía APIS del navegador
Un UUID v4 de un CSPRNG tiene mucha entropía, entonces, ¿por qué los revisores de seguridad todavía desaprueban los tokens UUID? Esta publicación separa la cuestión de la entropía de la cuestión del diseño.
El enlace de reinicio que utiliza el UUID de la fila: un acceso directo común y dos razones muy diferentes por las que podría no ser seguro
Un atajo común: utilice el identificador de fila UUID del usuario como token de restablecimiento de contraseña. La tabla tiene una columna uuid; es único; es difícil de adivinar (si es una v4). La URL es /reset? token=550e8400-e29b-41d4-a716-446655440000. Un revisor de seguridad lo rechaza inmediatamente, no porque UUID sea débil, sino porque combina dos preocupaciones que deberían ser independientes. La fila UUID es estable y normalmente visible públicamente (en URL, API, registros). El token de reinicio debe ser de un solo uso y secreto. Reutilizar la fila UUID como token significa que la identidad del usuario y su credencial restablecida tienen el mismo valor y la credencial vive para siempre en lugar de caducar. Un atacante que conozca la identificación del usuario puede realizar un reinicio. Un usuario que copió y pegó un enlace de restablecimiento hace cinco años aún puede usarlo. Estos son errores de diseño, no errores de entropía.
Comprobación de entropía: 122 bits aleatorios: por qué una v4 generada por CSPRNG no se puede adivinar mediante fuerza bruta
La verificación de aleatoriedad es necesaria pero no suficiente. La versión 4 reserva cuatro bits de versión y dos bits de variante, dejando 128 - 4 - 2 = 122 posiciones aleatorias cuando la implementación llena los otros campos de forma aleatoria. Esa derivación no dice nada sobre caducidad, almacenamiento o autorización. La verificación del generador pregunta si esos campos provienen de un CSPRNG en lugar de Math.random o una marca de tiempo. ToolAcre satisface ese límite del generador. La verificación del diseño sigue siendo específica de la aplicación: una credencial restablecida necesita un ciclo de vida separado, una representación almacenada unidireccional, invalidación después de un uso exitoso y una caducidad elegida de la política de riesgos del servicio. La reutilización de la identificación del registro permanente del usuario falla en esa separación incluso cuando la identificación se generó de forma segura.
Comprobación del generador: dónde fallan realmente los tokens UUID: generación basada en Math.random, marcas de tiempo v1 y direcciones MAC, y semillas predecibles
Un ejemplo práctico: un esquema de restablecimiento de contraseña que falla y luego pasa las tres comprobaciones. Falla la verificación de entropía: el servidor emite un token de reinicio a través de Math.random(), empaquetado como v4 UUID. Un atacante observa tres fichas y predice la cuarta. No pasa la verificación del generador: el servidor usa una v1 UUID como token de reinicio, incluida la marca de tiempo de creación y la dirección MAC en el valor. Un atacante lee la marca de tiempo, descubre cuándo se emitió el reinicio y reduce la ventana de búsqueda. Pasa la verificación de entropía pero falla la verificación de diseño: el servidor usa un UUID v4 de crypto.getRandomValues, pero lo almacena en texto sin formato en la base de datos y no establece una caducidad. Un atacante que viola la base de datos lee tokens de reinicio y los usa para restablecer cuentas semanas después. Los tres controles son independientes; debes aprobar los tres.
Verificación de diseño: identificador versus credencial: por qué reutilizar la clave principal de un registro como secreto combina dos cosas que deberían rotar de forma independiente
Un esquema de token de reinicio que pasa las comprobaciones de entropía y generador pero no pasa la verificación de diseño (sin hash, sin caducidad, sin invalidación por uso) sigue siendo vulnerable. Manejo del token del lado del servidor: cuando un usuario solicita un restablecimiento de contraseña, genere un nuevo token aleatorio (no la fila UUID) de crypto.getRandomValues. Almacene una representación unidireccional en lugar del valor presentado, establezca una caducidad específica de la política e invalide el registro después de un uso exitoso. Cuando el usuario hace clic en el enlace, busque al usuario por correo electrónico, obtenga el hash almacenado, compare el token proporcionado con el hash, verifique la caducidad y ejecute el restablecimiento solo si el token es válido y aún no ha caducado. Invalide inmediatamente el token (bórrelo o márquelo como usado) para que no pueda reutilizarse. Nunca registre el token sin formato; registre sólo el ID de usuario y la acción.
Manejo del token del lado del servidor: almacene un hash, establezca una caducidad, invalide en uso y nunca registre el valor sin procesar
El token nunca debe aparecer en mensajes de error o en la base de datos a menos que esté codificado. El diseño de autenticación completa está más allá del alcance de un artículo UUID, pero los principios se mantienen: un token aleatorio de 122 bits no es inherentemente un token de acceso. La aleatoriedad es la parte fácil; el generador ToolAcre le proporciona UUID respaldados por CSPRNG. La parte difícil es el diseño: hash antes del almacenamiento, establecer tiempos de caducidad, invalidar en el uso, evitar la reutilización de identificaciones permanentes como secretos temporales, auditar quién accedió a qué y cuándo. Un revisor de seguridad que aprueba un esquema de reinicio de enlace basado únicamente en la entropía del token se está saltando el resto del análisis. Un desarrollador que piensa que un UUID respaldado por CSPRNG es suficiente para un enlace de restablecimiento de contraseña sin hash, caducidad e invalidación está subestimando la amenaza. La aleatoriedad defiende contra las conjeturas; el diseño defiende contra la repetición, la caducidad y el mal uso.
Ejemplo resuelto: revisar un esquema de enlace de reinicio en cada verificación y reescribir las partes débiles
El generador ToolAcre hace bien la parte de aleatoriedad; la aplicación debe hacer bien la parte del diseño. Pruebe su propio código de restablecimiento de enlace con las tres comprobaciones: ¿utiliza un CSPRNG (crypto.getRandomValues, crypto.randomUUID o una biblioteca de criptografía), no Math.random? ¿El token tiene tiempo de vencimiento? ¿Se aplica hash al token antes del almacenamiento? ¿Se invalida el token después de su uso? ¿El código evita reutilizar la identificación permanente del usuario como token temporal? Si responde afirmativamente a todas estas preguntas, el diseño de su enlace de reinicio es sólido. El generador ToolAcre es la parte CSPRNG; el resto es código de aplicación que debes revisar detenidamente. Comprender las tres capas de seguridad le ayuda a auditar bibliotecas y marcos UUID de terceros. Cuando evalúe una biblioteca, verifique que utilice un CSPRNG (verificación de entropía), no una fuente aleatoria débil. Compruebe que documente qué fuentes utiliza y por qué (verificación del generador).
Lo que esto no cubre: diseño de autenticación completa, MFA y limitación de velocidad, que son tan importantes como la entropía del token.
Verifique que el código de ejemplo y la documentación enfaticen los principios de diseño: hash, caducidad, invalidación (verificación de diseño). Las bibliotecas que pasan los tres controles son raras; la mayoría se centra únicamente en la entropía. El generador ToolAcre pasa las comprobaciones de entropía y generador mediante crypto.getRandomValues. La verificación del diseño es su responsabilidad; la biblioteca no puede conocer sus requisitos de caducidad ni su estrategia de hash. La depuración de un sistema de enlace de reinicio roto generalmente revela una de las tres fallas. Si los usuarios informan haber recibido enlaces de restablecimiento que ya no funcionan, el problema probable es la caducidad: el token se emitió pero expiró antes de que el usuario hiciera clic en el enlace. Si los tokens se reutilizan varias veces, se rompe la invalidación. Si aparecen tokens en mensajes de error o resultados de depuración, el registro los está filtrando. Si los enlaces de restablecimiento funcionan para un usuario pero no para otro, puede haber un retraso en la replicación de la base de datos o problemas de zona horaria con el cálculo de vencimiento. Si las solicitudes de restablecimiento legítimas fallan aleatoriamente, es posible que el CSPRNG esté roto (poco común).
Conclusión: la aleatoriedad es la parte fácil: el generador ToolAcre le brinda UUID respaldados por CSPRNG; el resto es disciplina de diseño
Comience con el registro: habilite registros de auditoría detallados para la generación y verificación del enlace de restablecimiento, luego reproduzca el problema y rastree el flujo. El generador ToolAcre garantiza que se pasen las dos primeras comprobaciones; La solución de problemas de restablecimiento de enlaces casi siempre entra en la categoría de diseño. Las mejores prácticas para los sistemas de enlace de restablecimiento de producción incluyen: generar un nuevo token aleatorio para cada solicitud de reinicio, no reutilizar tokens antiguos. Almacene una representación unidireccional junto con la cuenta y los metadatos de creación, luego elija un vencimiento de la política de riesgo documentada del servicio. Invalide el token inmediatamente después de una verificación exitosa. Registrar solicitudes de restablecimiento y éxitos para la auditoría. Implemente limitación de velocidad para evitar ataques de fuerza bruta. Envíe enlaces de restablecimiento únicamente por correo electrónico, no por SMS ni canales no cifrados. Notificar al usuario sobre intentos de restablecimiento de contraseña (para que pueda detectar restablecimientos no autorizados). El generador ToolAcre te brinda la aleatoriedad; seguir estas prácticas le brinda seguridad.