Les codes de sécurité textuels 2FA sont-ils délibérément faciles à retenir?
J'ai configuré 2FA sur mon compte bancaire. Lorsque je me connecte, je reçois un code à six chiffres en tant que messagerie instantanée sur mon téléphone que j'entre dans le site Web. Ces codes toujours semblent avoir un modèle. Soit quelque chose comme 111xxx, 123321, xx1212, etc.
Je pense que ces codes sont volontairement faciles à retenir d'un seul coup d'œil. Existe-t-il une pratique commerciale commune/meilleure pratique qui dicte que ces codes ont un modèle pour les rendre plus faciles à mémoriser?
J'ai également remarqué cela, et je pense que c'est le résultat du cerveau humain tendance à appliquer des motifs au bruit aléatoire . Cela semble être plus courant lorsque vous essayez spécifiquement de vous souvenir d'une chaîne de chiffres.
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 côte à côte. (Je suis heureux d'être corrigé sur mes mathématiques.)
Ces clés sont générées à l'aide de 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, le temps 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)
- Convenez d'une méthode de hachage cryptographique (la valeur par défaut est SHA-1)
- Convenez d'une longueur de jeton, N (la valeur par défaut est 6)
Bien que la RFC 6238 permette d'utiliser différents paramètres, l'implémentation Google de l'application d'authentification ne prend pas en charge les valeurs T0, TI, les méthodes de hachage et les longueurs de jeton différentes de celles par défaut. Il s'attend également à ce que la clé secrète K soit entrée (ou fournie dans un code QR) dans le codage en base 32 selon la RFC 3548.
Une fois les paramètres convenus, la génération de jetons est la suivante:
- Calculez C comme le nombre de fois où TI s'est écoulé après T0.
- 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 la plupart des bibliothèques cryptographiques le prennent en charge). K doit être passé tel quel, C doit être passé comme un entier brut non signé de 64 bits.
- Prenez au moins 4 bits significatifs de H et utilisez-le comme décalage, O.
- Prenez 4 octets de H à partir de O octets MSB, supprimez le bit le plus significatif et stockez le reste sous la forme d'un entier 32 bits (non signé), I.
- Le jeton est le N le plus bas de I dans la base 10. Si le résultat a moins de chiffres que N, remplissez-le avec des zéros à gauche.
Le serveur et le client calculent tous les deux le jeton, puis le serveur vérifie si le jeton fourni par le client correspond au jeton généré localement. Certains serveurs autorisent des codes qui auraient dû être générés avant ou après l'heure actuelle afin de tenir compte des légers décalages 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 sociétés. 62 de ceux-ci étaient longs de 6 chiffres. Voici le nombre de chaque chiffre:
Peut-être un léger biais vers 1,8 et 9? Presque certainement du bruit dans les données (62 est un petit échantillon).
Et les deux chiffres?
Le premier graphique n'est composé que de 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 tout placement (c'est-à-dire que XXX99X compte comme un double chiffre). Nous nous attendions à 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 chiffres doubles que non doubles - les chiffres doubles sont affichés en orange. Dans ces dernières données, nous nous attendons à environ 31 chiffres doubles, et nous obtenons 27. Cela semble raisonnable.
Bien sûr, cela n'exclut pas d'autres modèles "non aléatoires" - mais pour être honnête, les humains sont susceptibles de rechercher des modèles - regardez ces chiffres, tous tirés de mon application 2FA: 365 595, 111 216, 566 272, 468 694, 191 574, 833 043.
J'espère que ce n'est qu'une chance aléatoire 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 censés être intentionnellement faciles à mémoriser et il n'y a pas de cas commercial généralisé pour cela, sauf s'ils ont fait savoir que leurs utilisateurs avaient du mal à taper 6 chiffres. Alors quelqu'un aurait pu faire quelque chose de stupide, mais j'espère vraiment que non.
C'est aussi lié à la façon dont les humains ont tendance à penser au hasard. Dans le vrai hasard, les chiffres 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 assez 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 d'aspect aléatoire (sur la fausse croyance que les numéros d'aspect aléatoire sont plus susceptibles de gagner lors d'un tirage au sort).
Si un humain essaie d'émuler un tirage au sort aléatoire, il alternera beaucoup plus entre les têtes et les queues qu'il ne répétera le dernier résultat, ce qui permet de prédire leur prochaine valeur avec une assez bonne certitude (> 50% de chance leur prochaine valeur sera 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% d'un chiffre répété n'importe où), et très rare dans un "aléatoire" 6 -le chiffre que vous demandez à un humain de trouver.