Cum funcționează Google Authenticator?

Google Authenticator acceptă atât HOTP și TOTP algoritmi pentru generarea parolelor unice.

Cu HOTP, serverul și clientul partajează o valoare secretă și o contor, care sunt folosite pentru a calcula o parolă unică independent de ambele părți. Ori de câte ori este generată și utilizată o parolă, contorul este incrementat de ambele părți, permițând serverului și clientului să rămână sincronizate.

TOTP utilizează în esență același algoritm ca HOTP cu o diferență majoră. Contorul utilizat în TOTP este înlocuit cu ora curentă. Clientul și s erver rămân sincronizate atât timp cât sistemul rămâne același. Acest lucru se poate face utilizând protocolul Network Time .

Cheia secretă (precum și contorul în cazul HOTP) are să fie comunicat atât serverului, cât și clientului la un moment dat. În cazul Google Authenticator, acest lucru se face sub forma unui URI codat QRCode. Consultați: KeyUriFormat pentru mai multe informații.

Comentarii

• În cazul HOTP, de unde știe Google Authenticator că am " folosit " parola fără sincronizare cu serverul? Ceea ce face Google Authenticator este că continuă să clipească diferite taste și pot să le folosesc pe oricare dintre ele fără a oferi feedback mobilului meu.
• @MarioAwad Răspunsul la acest lucru poate fi găsit pe HOTP RFC, secțiunea 7.4 . ietf.org/rfc/rfc4226.txt
• Vă mulțumim pentru răspunsul și urmărirea bine definite. Rezumatul rapid al secțiunii 7.4: Resincronizarea contorului din când în când și o fereastră anticipată pentru contor este ceea ce face lucrurile să funcționeze fără a necesita sincronizare instantanee.
• După cum a subliniat @TerryChia, cheia secretă este în codul QR. Fiți conștienți de sensibilitatea codului QR / informații. Am scris o postare pe blog acum ceva timp netknights.it/en/the-problem-with-the-google-authenticator

De lucru:

Authenticator implementează algoritmul Time-Based One-Time Password (TOTP). Are următoarele ingrediente:

• Un secret partajat (o secvență de octeți)

• O intrare derivată din ora curentă

• O funcție de semnare

Secret comun: Secretul comun este ceea ce trebuie să obțineți pentru a configura contul pe telefonul dvs. . Fie faceți o fotografie a unui cod QR folosind telefonul, fie puteți introduce secretul manual.

Introducere (Ora curentă): Valoarea timpului de intrare pe care o veți obține pur și simplu de pe telefon, nu este necesară nicio interacțiune ulterioară cu serverul după ce ați obținut secretul. Cu toate acestea, este important ca timpul telefonului dvs. să fie corect ca serverul va repeta în esență ceea ce se întâmplă pe telefonul dvs. folosind ora curentă așa cum este cunoscută de server.

Funcția de semnare: Funcția de semnare utilizată este HMAC-SHA1. HMAC reprezintă codul de autentificare a mesajelor bazat pe Hash și este un algoritm care folosește o funcție hash securizată unidirecțională (SHA1 în acest caz) pentru a semna o valoare. Utilizarea unui HMAC ne permite să verificăm autenticitatea – numai persoanele care cunosc secretul pot genera aceeași ieșire pentru aceeași intrare (ora curentă).

Algoritm OTP :

Cod pseudo:

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 

Referință: https://garbagecollected.org/2014/09/14/how-google-authenticator-works/

Verificați și acest proiect github pentru implementarea GO: https://github.com/robbiev/two-factor-auth/blob/master/main.go

Comentarii

• Nu ' autentificatorul google acceptă și HOTP?

Va funcționa pe o sămânță în funcție de timp, astfel încât să fie similar cu modul în care Foburile cheie RSA funcționează. adică nu necesită nici o conectivitate.

Tocmai am aruncat o privire în jur și acest lucru este răspuns aici: https://stackoverflow.com/questions/8340495/how-rsa-tokens-works

Dacă unul strace este sshd daemon, se poate vedea cum serverul „știe” despre cheia secretă, în timp ce citește fișierul de configurare a utilizatorilor:

#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] 

Telefonul mobil îl știe deja; l-ați scanat prin QR sau l-ați introdus.

Comentarii

• Acesta este un bun exemplu pentru a demonstra că jetoanele sunt nu a fost trimis la server, dar nu ' nu explică de fapt cum funcționează (ceea ce a cerut OP)
• Nu ' t în sine, dar abordează lipsa de conectivitate.