En resumen, no. Mongo ObjectIds son fáciles de adivinar. En particular, bajo una carga alta, estos son a menudo números consecutivos, porque la marca de tiempo, la máquina y la identificación del proceso no cambian. Si observa la estructura de Objectid
, están compuestos por
a 4-byte timestamp,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
Por lo tanto, tienen muy poca aleatoriedad. A menudo veo identificaciones consecutivas en la base de datos, por ejemplo, si alguna acción del controlador escribe un objeto de dominio y una entrada de registro en rápida sucesión.
Si se puede adivinar la marca de tiempo y se puede determinar la identificación de la máquina (que es a menos que tenga un clúster enorme), solo quedan cinco bytes. Al observar una cantidad de identificaciones generadas, probablemente pueda reducir eso a 50 procesos, por lo que la entropía efectiva está en algún lugar en el rango de 28 bits. Todavía es difícil de adivinar, pero es demasiado arriesgado para un token de acceso.
En su lugar, use un generador de números pseudoaleatorios criptográficamente fuerte y cree un token a partir de eso. Por ejemplo, en .NET, el RNGCryptoServiceProvider permite crear datos aleatorios de longitud arbitraria.
Como nota al margen, sugiero tener un envoltorio criptográfico adicional alrededor de sus OAuthTokens, por dos razones:
a) Desea poder determinar tokens no válidos rápidamente. Un shell criptográfico válido aún puede incluir un token no válido (una concesión revocada o caducada), pero no tiene que acceder a la base de datos en ataques de fuerza bruta cada vez. Además, el cliente
b) Los clientes pueden solicitar tokens una y otra vez. Si bien no es un requisito, casi todos los sistemas que conozco devuelven tokens diferentes cada vez (sin importar si se autovalidan o no). Por lo general, eso se debe a que el token en sí tiene un período de validez limitado. Ese no es el mismo período de validez que tiene la concesión de OAuth.
En la base de datos, lo que realmente desea almacenar es la concesión, es decir, el permiso que le otorgó algún usuario a algún cliente. Si se elimina esta concesión, todos los tokens se vuelven inválidos. Insertar un nuevo token cada vez es muy poco práctico porque el usuario tendría que eliminarlos todos para eliminar efectivamente la concesión de la aplicación.
