Come funziona Google Authenticator?

Google Authenticator supporta sia HOTP e TOTP per la generazione di password monouso.

Con HOTP, il server e il client condividono un valore segreto e un counter, che vengono utilizzati per calcolare una password monouso indipendentemente su entrambi i lati. Ogni volta che viene generata e utilizzata una password, il contatore viene incrementato su entrambi i lati, consentendo al server e al client di rimanere sincronizzati.

TOTP utilizza essenzialmente lo stesso algoritmo di HOTP con una grande differenza. Il contatore utilizzato in TOTP viene sostituito dallora corrente. Il client e s erver rimangono sincronizzati fintanto che i tempi di sistema rimangono gli stessi. Questo può essere fatto utilizzando il protocollo Network Time .

La chiave segreta (così come il contatore nel caso di HOTP) ha da comunicare sia al server che al client in un determinato momento. Nel caso di Google Authenticator, ciò avviene sotto forma di un URI codificato QRCode. Vedi: KeyUriFormat per ulteriori informazioni.

Commenti

• Nel caso di HOTP, come fa Google Authenticator a sapere che ho " utilizzato " la password senza sincronizzarmi con il server? Quello che fa Google Authenticator è che continua a lampeggiare chiavi diverse e posso usarne una qualsiasi senza fornire feedback al mio cellulare.
• @MarioAwad La risposta a questa domanda può essere trovata su HOTP RFC, sezione 7.4 . ietf.org/rfc/rfc4226.txt
• Grazie per la risposta ben definita e il seguito. Breve riepilogo della sezione 7.4: la risincronizzazione del contatore ogni tanto e una finestra di anteprima per il contatore è ciò che fa funzionare le cose senza richiedere la sincronizzazione istantanea.
• Come ha sottolineato @TerryChia, la chiave segreta è nel codice QR. Sii consapevole della sensibilità del QRCode / Informazioni. Qualche tempo fa ho scritto un post sul blog netknights.it/en/the-problem-with-the-google-authenticator

In funzione:

Authenticator implementa lalgoritmo TOTP (Time-Based One-Time Password). Ha i seguenti ingredienti:

• Un segreto condiviso (una sequenza di byte)

• Un input derivato dallora corrente

• Una funzione di firma

Segreto condiviso: Il segreto condiviso è ciò di cui hai bisogno per configurare laccount sul tuo telefono . O scatti una foto di un codice QR utilizzando il tuo telefono oppure puoi inserire il segreto manualmente.

Input (ora corrente): Il valore dellora di input che otterrai semplicemente dal tuo telefono, non è richiesta alcuna ulteriore interazione con il server una volta ottenuto il segreto. Tuttavia è importante che lora del tuo telefono sia precisa come quella del server essenzialmente ripeterà ciò che accade sul tuo telefono utilizzando lora corrente come conosciuta dal server.

Funzione di firma: La funzione di firma utilizzata è HMAC-SHA1. HMAC sta per codice di autenticazione del messaggio basato su hash ed è un algoritmo che utilizza una funzione hash unidirezionale sicura (SHA1 in questo caso) per firmare un valore. Lutilizzo di un HMAC ci consente di verificare lautenticità: solo le persone che conoscono il segreto possono generare lo stesso output per lo stesso input (lora corrente).

Algoritmo OTP :

Pseudo codice:

original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret))) input = CURRENT_UNIX_TIME() / 30 // sets a constant value for 30 seconds hmac = SHA1(secret + SHA1(secret + input)) //apply hashing offset = hmac[len(hmac)-1] & 0x0F //Last nibble four_bytes = hmac[offset : offset+4] //takes a subset of 4 bytes from 20 bytes large_integer = INT(four_bytes) //Covert four bytes to integer small_integer = large_integer % 1,000,00 //gives 6 digit code 

Riferimento: https://garbagecollected.org/2014/09/14/how-google-authenticator-works/

Dai unocchiata anche a questo progetto GitHub per limplementazione GO: https://github.com/robbiev/two-factor-auth/blob/master/main.go

Commenti

• ' t anche Google Authenticator supporta HOTP?

Funzionerà su un seme basato sul tempo, quindi è simile al modo in cui I portachiavi RSA funzionano. cioè, inoltre, non richiedono alcuna connettività.

Ho appena dato unocchiata in giro e la risposta è qui: https://stackoverflow.com/questions/8340495/how-rsa-tokens-works

Se strace è sshd demone, si può vedere come il server “conosce” la chiave segreta, poiché legge il file di configurazione dellutente:

#strace -f -v -e open /usr/sbin/sshd -p 2222 -dddd -f /etc/ssh/sshd_config 2>&1 | grep -i goog > > [pid 2105] open("/home/myuser/.google_authenticator", O_RDONLY) = 4 > > [pid 2105] open("/home/myuser/.google_authenticator~", > > O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_NOFOLLOW, 0400debug3: > > mm_sshpam_respond: pam_respond returned 1 [preauth] 

Il telefono cellulare lo sa già; lhai scansionato tramite QR o digitato.

Commenti

• Questo è un buon esempio di come dimostrare che i token sono non viene inviato al server, ma ' in realtà non spiega come funziona (che è ciò che OP ha chiesto)
• Non ' t di per sé, ma risolve la mancanza di connettività.