Se utilizzi l'autenticazione in due passaggi per accedere al tuo account Google, puoi ricevere un SMS sul tuo telefono cellulare con un codice di stile G- 123456 .
Penso di non aver mai ottenuto un codice con uno zero iniziale. C'è una ragione per questo o è solo un caso improbabile nel regno della casualità?
Questa è una scelta di implementazione classica per ridurre gli errori di immissione dei dati.
Le persone che si occupano di informatica o di sicurezza delle informazioni comprendono la differenza tra una stringa di testo e una serie di cifre che rappresenta un valore. Ma alle persone che sono state addestrate in finanza, contabilità e altri campi è stato insegnato a troncare gli zeri principali quando si tratta di numeri. È più probabile che vedano una riga di cifre come un "numero che ha un valore". Ad esempio, se vedono "000001", il loro cervello interpreta questo come valore "uno". Quando arriva il momento di inserire il codice, richiamano il valore "uno" e digitano di riflesso "1". Numericamente è un valore equivalente, ma come stringa di testo non è una corrispondenza esatta.
Il progettista del sistema ha diverse opzioni per affrontarlo.
Possono generare codici con zeri iniziali e consentire ai pochi utenti di commettere l'errore occasionale, costringendoli a reinserirlo. Ciò può dare all'app una reputazione che è difficile da usare.
Possono modificare il sistema di input in modo che corrispondano a corrispondenze di testo o corrispondenze di valori numerici. Ciò aumenta la complessità della logica di input dell'utente in un'area di sicurezza critica del codice. La cronologia dei difetti di sicurezza è un elenco di prove che mostra un aumento della complessità nell'elaborazione dell'input dell'utente, aumenta il rischio di errori di codifica che portano a vulnerabilità.
Possono generare il codice da un insieme limitato di numeri che non rischiano mai di causare confusione all'utente. Ciò riduce il possibile numero di combinazioni valide di circa il 10%, che il progettista del sistema deve tenere conto quando calcola la fattibilità di una forza bruta o di un attacco a indovinello casuale. Spostando la complessità nella sezione di generazione del codice e lontano dalla sezione di input dell'utente, gli errori di programmazione potrebbero essere meno propensi a creare vulnerabilità.
In definitiva, è un problema di fattori umani per una piccola parte della popolazione. Ma i sistemi di sicurezza sono già complessi, dispendiosi in termini di tempo e frustranti, quindi qualsiasi problema di usabilità che accresce la frustrazione degli utenti è davvero negativo per mantenere intenzionalmente un sistema di sicurezza (specialmente quello che stai cercando di commercializzare commercialmente.)
I lettori SMS di telefono hanno la tendenza a interpretare gli elementi di testo per facilitare la navigazione dell'utente. Questo include i numeri di telefono per una chiamata rapida, o aggiungi / salva per contattare.
L'utilizzo di un modello G-[1-9][0-9]{5} è quindi molto probabilmente un modo per evitare quel comportamento comune in modo che non impedisca ad altre azioni come copiare o attivare azioni inappropriate come la chiamata o il salvataggio da contattare.
Ho il sospetto che l'algoritmo sia basato strettamente su quello che usano per Google Authenticator, TOTP (se non esattamente lo stesso dato il contesto di utilizzo simile) e l'algoritmo utilizzato è stato adattato per garantire che il risultato fosse sempre di 6 cifre, basato su molti calcoli molto più grandi. Non ne so abbastanza del vero processo HMAC per dire con certezza che uno 0 non può finire nell'output ma è apparentemente improbabile. Ecco una ripartizione abbastanza dettagliata: link
Leggi altre domande sui tag sms entropy multi-factor