Bonjour,
Je vais couvrir une partie peu couverte sur le web: quel est la longueur idéal d’un token (jeton)?
Pour qu’il soit réutilisé (piraté) il faut qu’il y ai une collision, c’est à dire que le nombre aléatoire corresponde à celui que l’ont est de notre coté. Cela ne sert à rien d’avoir une grosse longueur si les nombres aléatoires générés sont de mauvaise qualités, car il pourrons être prédit.
Calcule
Avec 32 octets, soit 256Bits, il y as 1.15792089237e+77 possibilité, considérons que l’ont vas tomber par chance sur le bon token dés les 1er 0.01%, il faut donc tester: 1.15792089237e+77/10000=1.15792089237e+73, sachant que un token fait 32 octets et qu’il y as 1.15792089237e+73, cela fait: 1.15792089237e+73*32 donc 3.70534685559e+74 octets à tester. Soit 3.36999333339e+62To à tester. Ce qui corresponds à 1.17495778018e+59 années (oui 59 zeros) avec un réseau 1000Mbps. Les tokens plus grands que 32Bytes me semble inutile.
Plus petit?
Ne connaissant pas les futures innovations technologique (memristor, remplacement du silicium par quelque chose sans vrai limite de fréquence, loi de moore, …), sachant que la courbe est exponentiel (division par 2 réduit fortement la sécurité), sachant que un protocole est difficile à changer, que les futures matériel auront tous les générateurs de nombres aléatoires (voir wikipedia)… Je pense qu’il ne faut pas tomber en dessous de 16 octets, soit 128Bits. Si vous l’envoyé par le réseau en binaire, comptez 60 d’entête (header) tcp donc même avec 32 octets c’est votre entête tcp qui prendra tout la place (inutile donc de diminuer plus pour économiser du réseau).
Plus grands?
Après un certain moments cela n’est plus utile, les temps explose, les risques de collision sont presque null. Ne pas oublier que après 64 octets la taille ce fait sentir sur des packets réseau ne transportant que le token. Si vous n’avez pas de générateurs de nombres aléatoires (voir wikipedia) hardware comme sur les vieux matériel ou bas de gammes et que vous être sur un serveur, il y aura peu d’entropie (voir wikipedia). Donc dépasser 64 octet me semble inutile.
Conclusion
32 octets me semble un bonne taille en générale pour un bonne sécurité. Si la duré de vie du token est limité, si la sécurité n’est pas trés importante, si c’est juste utilisé pour switcher d’un serveur à l’autre dans un temps imparti vous pouvez utilisé 16 octets. Si la sécurité est critique et que le token est stoker et pas généré dynamiquement jusqu’as 64 octets peuvent être utilisé. Je met à part les clef privé (128-512 octets ou +) car les implications sont pas les mêmes et que je suis pas sur de maîtriser le sujet. J’utilise /dev/random pour les clefs/tokens stockés, et /dev/urandom pour les tokens dynamiques.
Je m’en sert pour ajouter un salt dynamique avec le mot de passe et comparer les hash coté server (envoie du token serveur -> client, hash, résultat client -> serveur). Le token n’étant jamais le mêmes la personne ne peu répété les packets réseau, cela permet d’authentifier la personne sans que le mot de passe puisse être intercepté ou répété.
Lien sympa: