J'ai remarqué cela aussi, et je pense que c'est le résultat de la tendance du cerveau humain à appliquer des modèles au bruit aléatoire. Cela semble être plus courant lorsqu'on essaie spécifiquement de se souvenir d'une chaîne de nombres.

Environ 85% des nombres aléatoires à six chiffres auront au moins un chiffre répétitif et 40% auront un chiffre séquentiel répétitif l'un à côté de l'autre. (Je suis heureux d'être corrigé sur mes calculs.)

Ces clés sont générées en utilisant l'algorithme TOTP standard. L'article résume cette implémentation, montrant qu'il n'y a aucun effort pour générer un nombre mémorable:

Selon la RFC 6238, l'implémentation de référence est la suivante:

• Générez une clé, K, qui est une chaîne d'octets arbitraire, et partagez-la en toute sécurité avec le client.
• Mettez-vous d'accord sur un T0, l'heure Unix pour commencer à compter les pas de temps à partir de, et un intervalle, TI, qui sera utilisé pour calculer la valeur du compteur C (les valeurs par défaut sont l'époque Unix comme T0 et 30 secondes comme TI)
• Accepter une méthode de hachage cryptographique (la valeur par défaut est SHA-1)
• Accepter une longueur de jeton, N (la valeur par défaut est 6)

Bien que la RFC 6238 autorise l'utilisation de différents paramètres, l'implémentation Google de l'application d'authentification ne prend pas en charge les valeurs T0, TI , méthodes de hachage et longueurs de jeton différentes de la valeur par défaut. Il s'attend également à ce que la clé secrète K soit entrée (ou fournie dans un code QR) en codage base 32 conformément à la RFC 3548.

Une fois les paramètres convenus, la génération de jetons est la suivante:

1. Calculez C comme le nombre de fois que TI s'est écoulé après T0.
2. Calculez le hachage HMAC H avec C comme message et K comme clé (l'algorithme HMAC est défini dans la section précédente, mais aussi la plupart des bibliothèques cryptographiques le supportent). K doit être passé tel quel, C doit être passé comme un entier non signé 64 bits brut.
3. Prenez les 4 bits les moins significatifs de H et utilisez-les comme offset, O.
4. Prenez 4 octets de H en commençant à O octets MSB, supprimez le bit le plus significatif et stockez le reste sous forme d'entier 32 bits (non signé), I.
5. Le jeton correspond aux N chiffres les plus bas de I en base 10. Si le résultat a moins de chiffres que N, remplissez-le de zéros à partir de la gauche.

Le serveur et le client calculer le jeton, puis le serveur vérifie si le jeton fourni par le client correspond au jeton généré localement. Certains serveurs autorisent les codes qui auraient dû être générés avant ou après l'heure actuelle afin de tenir compte des légers biais d'horloge, de la latence du réseau et des retards des utilisateurs.

Sur mon téléphone, j'avais environ 90 codes de vérification de diverses entreprises. 62 d'entre eux comportaient 6 chiffres. Voici le nombre de chaque chiffre:

Peut-être un léger biais vers 1,8 et 9? Presque certainement juste du bruit dans les données (62 est un petit échantillon).

Qu'en est-il des doubles chiffres?

Le premier graphique n'est que le deux chiffres sur les limites à 2 chiffres (c'est-à-dire AABBCC) - nous nous attendons donc à ce que chaque paire apparaisse environ 1,86 fois sur les 186 emplacements de chiffres possibles. Le second est n'importe quel placement (c'est-à-dire que XXX99X compte comme un double chiffre). Nous nous attendons à ce que chaque paire soit environ 3,1 fois sur les 310 emplacements.

Il ne semble pas y avoir de biais évident avec beaucoup plus de doubles chiffres que de non doubles - les doubles chiffres sont affichés en orange. Dans ces dernières données, nous nous attendrions à environ 31 chiffres à deux chiffres, et nous en obtenons 27. Cela semble raisonnable.

Bien sûr, cela n'exclut pas d'autres modèles "non aléatoires" - mais pour être honnêtes humains sont susceptibles de rechercher des modèles - regardez ces chiffres, tous extraits de mon application 2FA: 365 595, 111216, 566 272, 468 694, 191574, 833 043.

J'espère que ce n'est qu'un hasard dans votre cas. S'il y a un modèle, cela affaiblit tout l'intérêt d'avoir un deuxième code.

Non, ils ne sont pas intentionnellement censés être faciles à retenir et il n'y a pas de business case généralisé pour cela, sauf s'ils ont des commentaires indiquant que leurs utilisateurs avaient du mal à saisir 6 chiffres. Alors quelqu'un a peut-être fait quelque chose de stupide, mais j'espère vraiment que non.

Cela a aussi à voir avec la façon dont les humains ont tendance à penser au hasard. Dans le vrai hasard, les chiffres répétés et les motifs répétés se produisent beaucoup plus souvent que prévu. Lorsque les humains sont invités à créer des séquences de chiffres qui «semblent» aléatoires, ils ont tendance à éviter de répéter des motifs ou des chiffres (ainsi que d'autres bizarreries, comme la surutilisation de «7», et la sous-utilisation de «0» et «2», etc). Si vous demandez à quelqu'un de choisir un nombre «aléatoire» entre 1 et 100, il contiendra très souvent un 7, et bien souvent 37 (ou 17). Vous pouvez étudier les numéros de loterie que les gens choisissent manuellement, car (souvent) les gens essaient de choisir quelque chose qui semble aléatoire (sur la fausse croyance que les numéros aléatoires sont plus susceptibles de gagner dans un tirage au sort).

Si un humain essaie d'imiter un tirage au sort aléatoire, ils alterneront beaucoup plus entre les faces et les queues qu'ils ne répéteront le dernier résultat, ce qui permet de prédire leur prochaine valeur avec une assez bonne certitude (> 50% de chance que leur prochaine valeur soit être le contraire de leur dernier).

Une séquence de chiffres ou de deux chiffres répétée serait assez courante dans un vrai nombre aléatoire à 6 chiffres (par exemple ~ 41% d'un chiffre répété consécutif, ~ 85% de un chiffre répété n'importe où), et très rare dans un nombre "aléatoire" à 6 chiffres que vous demandez à un humain de trouver.