Enlace UUID marcador

Si se trata de un UUID bien generado (por ejemplo, no solo un número secuencial atascado en algo que parece UUID-y) y el sitio no contiene ningún dato particularmente sensible (por ejemplo, información de pago con tarjeta de crédito, direcciones personales, etc.) Probablemente no sea tan malo.

El defecto principal es el que mencionaste: si no es secreto, cualquiera tiene acceso. Eso implica que se debe usar HTTPS, con los encabezados de control de caché establecidos para evitar que los cachés intermedios almacenen la URL. Debería haber un método para desactivar un enlace determinado, luego de la verificación mediante un método diferente (por ejemplo, enviarles un enlace de desactivación), en caso de una fuga detectada.

También esperaría que el sitio implementara precauciones razonables para no cambiar otros detalles, como solicitar una contraseña antes de poder cambiar la dirección de correo electrónico registrada o también solicitar una cookie.

No querría usarlo para nada sensible, y ciertamente no para nada relacionado con pagos, información de identificación personal o información relacionada con la salud, sino para un juego en línea, sala de chat o similar (¡no he visitado el enlace!) no es terrible.

Hay varios métodos para generar UUID . El método 4 implica el uso de 122 bits de un generador aleatorio. Si ese generador es criptográficamente fuerte , entonces el UUID es una buena clave secreta. Pero puede ser difícil determinar si una implementación específica de la generación UUID usa el método 4 con un PRNG fuerte. En general, los UUID están destinados a singularidad , no a imprevisibilidad . Para un token de autenticación secreto, realmente necesita este último. Por ejemplo, si se usa un UUID "tipo 1" (combinación de la dirección MAC del sistema y la hora actual), los atacantes pueden inferir fácilmente qué UUID producirá su sistema para otros usuarios.

Dicho esto, en un sistema dado, podría usar manualmente un PRNG fuerte para obtener una secuencia impredecible de 128 bits, que sería una especie de UUID con las características necesarias.

Proporcionar el token de autenticación como parte de una URL que los usuarios pueden marcar tiene otro problema, y es que los usuarios lo marcarán como . El almacenamiento de valores secretos en una computadora de escritorio tiene algo de cuidado. Los navegadores aplican ese cuidado por las cookies, no por la URL. En particular, la URL se puede mostrar (y normalmente lo hará). Esto sería un problema exactamente en el mismo sentido que no le gustaría una página web que muestre su contraseña: las personas que tengan un vistazo en su pantalla pueden obtener demasiada información.