¿Cómo generar tokens aleatorios pero únicos para la autenticación?

Usar os.urandom() está perfectamente bien. Genera un criptográficamente seguro flujo aleatorio de bytes. Esto sería imposible de adivinar para cualquiera.

El uso de guid() también es bastante seguro , aunque no totalmente aleatorio.

Usar XOR para codificar parámetros en tu token es una mala idea. Por un lado, es vulnerable a los ataques de volcado de bits. Incluso si el usuario no puede decodificar el token, puede alterar los contenidos codificados en él. Una mejor solución es enviar un HMAC junto con los datos, para que el usuario no pueda manipularlo.

El uso de os.urandom() utiliza fuentes criptográficamente seguras aceptadas, así que continúe usando esa si puede, de lo contrario debería haber otra forma de acceder a las mismas fuentes, o de manera similar, a fuentes aleatorias seguras en la implementación que está utilizando ( php java ). Lo más importante es que no puede ser predecible, lo que significa que cualquier tipo de siembra realizada manualmente (por ejemplo, usando el tiempo) es una mala idea.

Editar: ¿Puede aclarar qué quiere decir exactamente con 'usar XOR enc para almacenar datos en la cadena'?

Edición 2: me gustaría señalar que incluso utilizando un random GUID es no una buena manera de hacer esto ( excepto quizás en Java ). La mayoría de los métodos para crear un GUID son relativamente deterministas, y si bien pueden ser buenos para evitar colisiones, la otra característica que desea de un token de restablecimiento de contraseña es impredecible .

  

¿podemos usar XOR enc para almacenar datos en la propia cadena para optimizar las consultas de base de datos?

Sí, pero ya no se llamará un token, sino un ticket (si se usa un cifrado simétrico) o un certificado (si se usa un cifrado simétrico). Al igual que los tokens, los tickets y certificados son cadenas utilizadas para la autenticación, pero en realidad contienen datos encriptados y / o criptográficamente firmados, en lugar de solo un número aleatorio.

El servidor emite un ticket / certificado, que encripta los detalles de autenticación, como quién es el usuario, y sus permisos, el período de validez y la marca de tiempo, y posiblemente una sal. Para autenticarse, el servidor descifra el ticket / certificado y valida estos valores. Los tickets y certificados a menudo se usan en la autenticación distribuida sin un servidor central o donde el servidor central puede ser inaccesible desde la aplicación.

Los tickets y certificados son más difíciles de implementar de forma segura, en comparación con los tokens; pero debido a su naturaleza descentralizada, pueden escalar mejor y ser utilizables en situaciones donde la autenticación central no es posible.

Sin embargo, recomendaría algo más específico que el cifrado XOR. Mientras que XOR es parte de muchos cifrados de flujo, la parte difícil de hacer el cifrado XOR es generar el flujo pseudoaleatorio que usaste para XOR a los datos.