Ho impostato 2FA sul mio conto bancario. Quando accedo, ricevo un codice di sei cifre come IM sul mio telefono che accedo al sito web. Questi codici sempre sembrano avere un modello per loro. O qualcosa come 111xxx, 123321, xx1212, ecc.
Penso che questi codici siano intenzionalmente facili da ricordare a un solo sguardo. Esiste una pratica commerciale / pratica migliore che impone a questi codici uno schema per renderli più facili da ricordare?
Ho notato anche questo, e penso che sia il risultato della tendenza del cervello umano ad applicare pattern a 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 ricorrente e il 40% avrà una cifra sequenziale ripetitiva l'una accanto all'altra. (Sono felice di essere corretto sulla mia matematica.)
Queste chiavi sono generate utilizzando l'algoritmo TOTP standard . L'articolo riassume questa implementazione, mostrando che non c'è alcuno sforzo per generare un numero memorabile:
According to RFC 6238, the reference implementation is as follows:
- Generate a key, K, which is an arbitrary byte string, and share it securely with the client.
- Agree upon a T0, the Unix time to start counting time steps from, and an interval, TI, which will be used to calculate the value of the counter C (defaults are the Unix epoch as T0 and 30 seconds as TI)
- Agree upon a cryptographic hash method (default is SHA-1)
- Agree upon a token length, N (default is 6)
Although RFC 6238 allows different parameters to be used, the Google implementation of the authenticator app does not support T0, TI values, hash methods and token lengths different from the default. It also expects the K secret key to be entered (or supplied in a QR code) in base-32 encoding according to RFC 3548.
Once the parameters are agreed upon, token generation is as follows:
- Calculate C as the number of times TI has elapsed after T0.
- Compute the HMAC hash H with C as the message and K as the key (the HMAC algorithm is defined in the previous section, but also most cryptographical libraries support it). K should be passed as it is, C should be passed as a raw 64-bit unsigned integer.
- Take the least 4 significant bits of H and use it as an offset, O.
- Take 4 bytes from H starting at O bytes MSB, discard the most significant bit and store the rest as an (unsigned) 32-bit integer, I.
- The token is the lowest N digits of I in base 10. If the result has fewer digits than N, pad it with zeroes from the left.
Both the server and the client compute the token, then the server checks if the token supplied by the client matches the locally generated token. Some servers allow codes that should have been generated before or after the current time in order to account for slight clock skews, network latency and user delays.
Sul mio telefono ho ricevuto circa 90 codici di verifica da varie società. 62 di questi erano lunghi 6 cifre. Ecco il conteggio di ogni cifra:
Forse un leggero disallineamento verso 1,8 e 9? Quasi certamente solo rumore nei dati (62 è un piccolo campione).
E riguardo le doppie cifre?
Ilprimograficoèsololedoppiecifresuiconfinia2cifre(adesempioAABBCC),quindiciaspettiamocheciascunacoppiaappaiacirca1,86voltenei186possibiliposizionamentidicifre.Ilsecondoèqualsiasiposizionamento(adesempioXXX99Xcontacomeunadoppiacifra).Ciaspettiamocheognicoppiasiacirca3,1voltenei310posizionamenti.
Nonsembraessercialcunainclinazioneevidenteconmoltepiùcifredoppierispettoanondoppie:ledoppiecifresonomostrateinarancione.Negliultimidati,ciaspetteremmocirca31cifredoppieeotteniamo27.Ciòsembraragionevole.
Ovviamente,questononescludealtripattern"non casuali" - ma per essere onesti, è probabile che gli umani cerchino modelli - guarda questi numeri, tutti presi dalla mia app 2FA: 365 595, 111 216, 566 272, 468 694, 191 574, 833 043.
Spero che questa sia solo una casualità nel tuo caso. Se c'è un pattern, indebolisce l'intero punto di avere un secondo codice.
No, non sono intenzionalmente supposti facili da ricordare e non esiste un caso aziendale generalizzato a meno che non abbiano ricevuto un riscontro che i loro utenti hanno avuto problemi a digitare 6 numeri. Quindi qualcuno potrebbe aver fatto qualcosa di sciocco, 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 dovrebbero. Quando agli umani viene chiesto di creare sequenze di cifre che "sembrano" casuali, tendono a evitare ripetizioni di pattern o cifre (così come altre stranezze, come l'eccessivo uso di "7" e l'uso insufficiente di "0" e "2", eccetera). Se chiedi a qualcuno di scegliere un numero "casuale" compreso tra 1 e 100, conterrà molto spesso un 7 e molto spesso 37 (o 17). Puoi studiare i numeri della lotteria che le persone scelgono manualmente (spesso) le persone cercano di scegliere qualcosa di casuale (sulla falsa credenza che i numeri dall'aspetto casuale abbiano più probabilità di vincere in un sorteggio casuale).
Se un umano sta cercando di emulare un lancio casuale di una moneta, si alterneranno tra testa e croce molto più di quanto non ripeteranno l'ultimo risultato, rendendo possibile prevedere il loro prossimo valore con una discreta certezza (> 50% possibilità che il loro prossimo valore sia l'opposto del loro ultimo).
Una sequenza ripetuta o una sequenza di due cifre sarebbe abbastanza comune in un numero casuale a 6 cifre (ad esempio ~ 41% di una cifra ripetuta consecutiva, ~ 85% di una cifra ripetuta in qualsiasi punto), e molto rara in un " casuale "numero di 6 cifre che chiedi a un umano di venire fuori.
Leggi altre domande sui tag multi-factor