Bref, non. Mongo ObjectIds sont faciles à deviner. En particulier, sous forte charge, il s'agit souvent de nombres consécutifs, car l'horodatage, l'identifiant de la machine et du processus ne changent pas. Si vous regardez la structure d'Objectid
, ils sont composés de
a 4-byte timestamp,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
Par conséquent, ils ont très peu d'aléatoire. Je vois souvent des identifiants consécutifs dans la base de données, par exemple si une action du contrôleur écrit un objet de domaine et une entrée de journal en succession rapide.
Si l'horodatage peut être deviné et que l'ID de la machine est déterminable (ce qui n'est le cas que si vous avez un énorme cluster), il ne reste que cinq octets. En examinant un certain nombre d'identifiants générés, je peux probablement réduire cela à 50 processus, de sorte que l'entropie effective se situe quelque part dans la plage de 28 bits. C'est encore difficile à deviner, mais c'est beaucoup trop risqué pour un jeton d'accès.
Utilisez plutôt un générateur de nombres pseudo-aléatoires cryptographiquement fort et créez un jeton à partir de celui-ci. Par exemple, dans .NET, le RNGCryptoServiceProvider permet de créer des données aléatoires de longueur arbitraire.
En passant, je suggère d'avoir un wrapper cryptographique supplémentaire autour de vos OAuthTokens, pour deux raisons :
a) Vous voulez être en mesure de déterminer rapidement les jetons non valides. Un shell cryptographique valide peut toujours inclure un jeton non valide (une autorisation révoquée ou expirée), mais vous n'avez pas à frapper la base de données lors d'attaques par force brute à chaque fois. Aussi, le client
b) Les clients peuvent demander des jetons encore et encore. Bien que ce ne soit pas une exigence, presque tous les systèmes que je connais renvoient des jetons différents à chaque fois (qu'ils s'auto-valident ou non). Habituellement, c'est parce que le jeton lui-même a une période de validité limitée. Ce n'est pas la même période de validité que la subvention OAuth.
Dans la base de données, ce que vous voulez vraiment stocker, c'est l'octroi, c'est-à-dire l'autorisation qui a été donnée par un utilisateur à un client. Si cette subvention est supprimée, tous les jetons deviennent invalides. L'insertion d'un nouveau jeton à chaque fois est très peu pratique car l'utilisateur devrait tous les supprimer pour supprimer efficacement la subvention de l'application.
