Anch'io l'ho notato e penso che sia il risultato della tendenza del cervello umano ad applicare schemi al rumore casuale. Questo sembra essere più comune quando si cerca specificamente di ricordare una stringa di numeri.

Circa l'85% dei numeri casuali a sei cifre avrà almeno una cifra ripetuta e il 40% avrà una cifra sequenziale ripetuta una accanto all'altra. (Sono felice di essere corretto in matematica.)

Queste chiavi vengono generate utilizzando l'algoritmo TOTP standard. L'articolo riassume questa implementazione, mostrando che non c'è alcuno sforzo per generare un numero memorabile:

Secondo RFC 6238, l'implementazione di riferimento è la seguente:

• Genera una chiave, K, che è una stringa di byte arbitraria, e condividila in modo sicuro con il client.
• Concorda un T0, l'ora Unix da cui iniziare a contare i passi temporali e un intervallo, TI, che verrà utilizzato per calcolare il valore del contatore C (i valori predefiniti sono l'epoca Unix come T0 e 30 secondi come TI)
• Concordare un metodo hash crittografico (il valore predefinito è SHA-1)
• Concordare una lunghezza del token, N (il valore predefinito è 6)

Sebbene RFC 6238 consenta l'utilizzo di parametri diversi, l'implementazione Google dell'app di autenticazione non supporta T0, valori TI , metodi hash e lunghezze di token diverse da quelle predefinite. Si aspetta inoltre che la chiave segreta K venga inserita (o fornita in un codice QR) nella codifica base 32 secondo RFC 3548.

Una volta concordati i parametri, la generazione del token è la seguente:

1. Calcola C come numero di volte in cui TI è trascorso dopo T0.
2. Calcola l'hash HMAC H con C come messaggio e K come chiave (l'algoritmo HMAC è definito in la sezione precedente, ma anche la maggior parte delle biblioteche crittografiche lo supportano). K dovrebbe essere passato così com'è, C dovrebbe essere passato come intero senza segno a 64 bit.
3. Prendi i 4 bit meno significativi di H e usali come offset, O.
4. Prendi 4 byte da H a partire da O byte MSB, elimina il bit più significativo e memorizza il resto come un numero intero (senza segno) a 32 bit, I.
5. Il token è le N cifre più basse di I in base 10. Se il risultato ha meno cifre di N, riempilo con zeri da sinistra.

Sia il server che il client calcolare il token, quindi il server controlla se il token fornito dal client corrisponde al token generato localmente. Alcuni server consentono codici che avrebbero dovuto essere generati prima o dopo l'ora corrente per tenere conto di lievi disallineamenti dell'orologio, latenza di rete e ritardi degli utenti.

Sul mio telefono avevo circa 90 codici di verifica di varie aziende. 62 di questi erano lunghi 6 cifre. Ecco il conteggio di ogni cifra:

Forse una leggera inclinazione verso 1,8 e 9? Quasi certamente solo rumore nei dati (62 è un piccolo campione).

E le doppie cifre?

Il primo grafico è solo il doppie cifre sui limiti a 2 cifre (cioè AABBCC), quindi ci aspetteremmo che ogni coppia appaia circa 1,86 volte attraverso i 186 possibili posizionamenti di cifre. Il secondo è qualsiasi posizionamento (ad esempio XXX99X conta come una doppia cifra). Ci aspettiamo che ogni coppia sia circa 3,1 volte nei 310 posizionamenti.

Non sembra esserci alcuna inclinazione evidente con molte più cifre doppie rispetto alle cifre non doppie - doppie sono mostrate in arancione. In questi ultimi dati, ci aspetteremmo circa 31 cifre doppie e ne otteniamo 27. Sembra ragionevole.

Ovviamente, questo non esclude altri modelli "non casuali", ma ad essere onesti gli esseri umani è probabile che stiano cercando modelli: guarda questi numeri, tutti presi dalla mia app 2FA: 365 595, 111216, 566 272, 468 694, 191 574, 833 043.

Spero che questa sia solo una casualità nel tuo caso. Se c'è uno schema, indebolisce l'intero punto di avere un secondo codice.

No, non dovrebbero essere intenzionalmente facili da ricordare e non esiste un caso aziendale generalizzato a meno che non abbiano ricevuto feedback che i loro utenti avevano problemi a digitare 6 numeri. Allora qualcuno potrebbe aver fatto qualcosa di stupido, ma spero davvero di no.

Ha anche a che fare con il modo in cui gli umani tendono a pensare alla casualità. Nella vera casualità, le cifre ripetute e gli schemi ripetuti si verificano molto più spesso di quanto ci aspettiamo. Quando agli esseri umani viene chiesto di creare sequenze di cifre che "sembrano" casuali, tendono a evitare di ripetere schemi o cifre (così come altre stranezze, come l'uso eccessivo di "7" e il sottoutilizzo di "0" e "2", eccetera). Se chiedi a qualcuno di scegliere un numero "casuale" compreso tra 1 e 100, molto spesso conterrà un 7 e molto spesso sarà 37 (o 17). Puoi studiare i numeri della lotteria che le persone scelgono manualmente poiché (spesso) le persone cercano di scegliere qualcosa di casuale (sulla falsa convinzione che i numeri dall'aspetto casuale abbiano maggiori probabilità di vincere in un'estrazione casuale).

Se un umano sta cercando di emulare un lancio casuale di una moneta, alternerà testa e croce molto più di quanto ripeterà l'ultimo risultato, rendendo possibile prevedere il loro prossimo valore con una certezza abbastanza buona (> 50% di possibilità che il loro prossimo valore sarà essere l'opposto del loro ultimo).

Una cifra ripetuta o una sequenza di due cifre sarebbe abbastanza comune in un vero numero casuale a 6 cifre (ad esempio ~ 41% di una cifra ripetuta consecutiva, ~ 85% di una cifra ripetuta ovunque) e molto raro in un numero "casuale" di 6 cifre che chiedi a un essere umano di inventare.